[Bug target/85667] (x86_64) ms_abi rules aren't followed when returning short structs with float values

[green at redhat dot com]

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

Anthony Green  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu
   Priority|P3  |P2

[Bug target/85667] New: (x86_64) ms_abi rules aren't followed when returning short structs with float values

[green at redhat dot com]

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

Bug ID: 85667
   Summary: (x86_64) ms_abi rules aren't followed when returning
short structs with float values
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: green at redhat dot com
  Target Milestone: ---

Structs 8 bytes or shorter with floating point values should return in eax.

GCC 8.0.1 (at least) doesn't follow those rules.  It is using the sysv ABI
rules instead.

See this code, for example:

typedef struct
{
  float x;
} Float;

Float  __attribute__((ms_abi)) fn1()
{
  Float v;
  v.x = 3.145;
  return v;
}

Float fn2 ()
{
  Float v;
  v.x = 3.145;
  return v;
}


GCC's output for fn1 and fn2 are similar:

fn1:
movss   .LC0(%rip), %xmm0
ret

fn2:
movss   .LC0(%rip), %xmm0
ret


Clang does this correctly, however, and fn1 looks like this:

fn1:
movl$1078544302, %eax
retq

fn2: 
movss   .LCPI1_0(%rip), %xmm0 
retq

[Bug c/85664] Don't ask questions if tere's no way to answer

[gcc at mailed dot e4ward.com]

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

--- Comment #2 from Mysha  ---
Well,  Jonathan Wakely, I hear there's not enough love to go round.

But other than that: Yes, that is indeed one case of the compiler asking a
question where it shouldn't. And I like the approach of replacing it with
something like:
  #include  defines std::foo.
Indeed, I do have the impression that messages aren't as terse as they used to
be. Informative, but not really terse. And this would seem a nice short
alternative.


Another one case is the result from compiling program test.c:
inf main(){}

"
test.c:1:1: error: unknown type name ‘inf’; did you mean ‘int’?
 inf main(){}
 ^~~
 int
"

I don't know how many more unanswerable questions there are in GCC, but
reactions suggest that these informative messages with questions are not an
option, but rather the normal output. In that case, I'd rather have --terse;
just the error messages, not the informative additions. (I get a lot of these,
and with four lines per error I run our of console lines after some 17 typos.)

But for the direct case: While the other one also would like to see the wording
changed, that one is about the verbosity; what I'm after are the questions. If
there's no checksum in those files, I figure I can just hexedit them, but I'd
prefer a proper solution to that.

Bye
Mysha

[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution

[emsr at gcc dot gnu.org]

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

--- Comment #4 from emsr at gcc dot gnu.org ---
Created attachment 44079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44079=edit
Patch for trunk and branch-8.

Ok, i was looking at backporting this and there are two more places in 
  gamma_distribution<_RealType>::
  __generate_impl(_ForwardIterator __f, _ForwardIterator __t,
  _UniformRandomNumberGenerator& __urng,
  const param_type& __param)
where this same bit is pasted!

So I'll patch trunk on down.

[Bug c++/85662] [8/9 Regression] "error: non-constant condition for static assertion" from __builtin_offsetof in C++

[roland at gnu dot org]

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

--- Comment #4 from roland at gnu dot org ---
That fix (applied to trunk) works for my test case and for the original
real-world case I reduced it from.

Will it be backported to 7 and 8?


Thanks for the quick work as usual, Jakub!

[Bug other/77609] __attribute__((section(".note.foo"))) forces SHT_PROGBITS though the assembler would use SHT_NOTE

[roland at gcc dot gnu.org]

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

--- Comment #4 from roland at gcc dot gnu.org ---
Author: roland
Date: Sat May  5 23:35:25 2018
New Revision: 259969

URL: https://gcc.gnu.org/viewcvs?rev=259969=gcc=rev
Log:
PR other/77609: Let the assembler choose ELF section types for miscellaneous
named sections

gcc/
PR other/77609
* varasm.c (default_section_type_flags): Set SECTION_NOTYPE for
any section for which we don't know a specific type it should have,
regardless of name.  Previously this was done only for the exact
names ".init_array", ".fini_array", and ".preinit_array".
(default_elf_asm_named_section): Add comment about
relationship with default_section_type_flags and SECTION_NOTYPE.
(get_section): Don't consider it a type conflict if one side has
SECTION_NOTYPE and the other doesn't, as long as neither has the
SECTION_BSS et al used in the default_section_type_flags logic.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/varasm.c

[Bug target/85666] gcc-8.0.1 fails to build mmix target: gcc/libgcc/libgcc2.h:203:20: internal compiler error: in leaf_function_p, at final.c:4488

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #2 from Sergei Trofimovich  ---
Perhaps was introduced by this commit:
https://github.com/gcc-mirror/gcc/commit/6e0eb5c3537ca9a28f5580e5ef1f3d772f98d64e

"Add an assert to leaf_function_p to ensure it is not called from a prolog or
epilog sequence ..."

[Bug target/85666] gcc-8.0.1 fails to build mmix target: gcc/libgcc/libgcc2.h:203:20: internal compiler error: in leaf_function_p, at final.c:4488

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  ---
looks like leaf_function_p() predicate fails right at start of cfgexpand when
it tries to pick stack frame size. leaf_function_p() has a few hints that it's
knowingly trying to do it before expand finishes:

Crash happens at:
https://github.com/gcc-mirror/gcc/blob/master/gcc/cfgexpand.c#L6630

 static rtx_insn *
 expand_used_vars (void)
 {
  tree var, outer_block = DECL_INITIAL (current_function_decl);
  auto_vec maybe_local_decls;
  rtx_insn *var_end_seq = NULL;
  unsigned i;
  unsigned len;
  bool gen_stack_protect_signal = false;

  /* Compute the phase of the stack frame for this function.  */
  {
int align = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
int off = targetm.starting_frame_offset () % align; /// <- here
frame_phase = off ? align - off : 0;
  }
 ...

targetm.starting_frame_offset is 

 static HOST_WIDE_INT
 mmix_starting_frame_offset (void)
 {
  return
(-8
 + (MMIX_CFUN_HAS_LANDING_PAD
-16 : (MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS ? -8 : 0))); // <- here
 }

MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS triggers assertion:
  https://github.com/gcc-mirror/gcc/blob/master/gcc/config/mmix/mmix.c#L61

 #define MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS\
  (flag_exceptions  \
   && ((reload_completed && df_regs_ever_live_p (MMIX_rJ_REGNUM))   \
 || !leaf_function_p ())) /// <- here

[Bug c/85666] New: gcc-8.0.1 fails to build mmix target: gcc/libgcc/libgcc2.h:203:20: internal compiler error: in leaf_function_p, at final.c:4488

[slyfox at inbox dot ru]

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

Bug ID: 85666
   Summary: gcc-8.0.1 fails to build mmix target:
gcc/libgcc/libgcc2.h:203:20: internal compiler error:
in leaf_function_p, at final.c:4488
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

gcc-7.3.0 worked. gcc-8.0.1 fails as:

/home/slyfox/dev/git/gcc-mmix/./gcc/xgcc -B/home/slyfox/dev/git/gcc-mmix/./gcc/
-B/home/slyfox/dev/git/gcc-mmix/../gcc-mmix-installed/mmix/bin/
-B/home/slyfox/dev/git/gcc-mmix/../gcc-mmix-installed/mmix/lib/ -isystem
/home/slyfox/dev/git/gcc-mmix/../gcc-mmix-installed/mmix/include -isystem
/home/slyfox/dev/git/gcc-mmix/../gcc-mmix-installed/mmix/sys-include-g -O2
-mabi=gnu -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -mlibfuncs
-O2 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -mlibfuncs -O2 -I.
-I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS -o _divdi3.o -MT _divdi3.o -MD -MP -MF _divdi3.dep
-DL_divdi3 -c ../../../../gcc/libgcc/libgcc2.c \
  -fexceptions -fnon-call-exceptions 
during RTL pass: expand
In file included from ../../../../gcc/libgcc/libgcc2.c:56:
../../../../gcc/libgcc/libgcc2.c: In function '__divti3':
../../../../gcc/libgcc/libgcc2.h:203:20: internal compiler error: in
leaf_function_p, at final.c:4488
 #define __NDW(a,b) __ ## a ## ti ## b
^~
../../../../gcc/libgcc/libgcc2.h:274:18: note: in expansion of macro '__NDW'
 #define __divdi3 __NDW(div,3)
  ^
../../../../gcc/libgcc/libgcc2.c:1231:1: note: in expansion of macro '__divdi3'
 __divdi3 (DWtype u, DWtype v)
 ^~~~
0x7f724decda56 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,

$ gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: mmix
Configured with: ../gcc/configure --target=mmix
--prefix=/home/slyfox/dev/git/gcc-mmix/../gcc-mmix-installed
--with-sysroot=/usr/mmix --disable-bootstrap --enable-languages=c --disable-nls
--with-native-system-header-dir=/include CFLAGS=-O0 CXXFLAGS=-O0
Thread model: single
gcc version 9.0.0 20180505 (experimental) (GCC)

[Bug c/85664] Don't ask questions if tere's no way to answer

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Jonathan Wakely  ---
See also PR 84890 (I think this could be considered a duplicate of that one).

[Bug target/85665] Multiple typos in diagnostics

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
It might be better to report multiple bugs, one per target backend, so that the
relevant target maintainers are informed.

To avoid similar problems in future, I wonder if a weekly email detailing any
new or modified diagnostics could be produced automatically. The diagnostics
maintainers (and anybody else interested) could look over it and ensure that we
use correct grammar, punctuation, and style.

[Bug target/85665] Multiple typos in diagnostics

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-05
 Ever confirmed|0   |1

[Bug c/85665] Multiple typos in diagnostics

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
To give a bit of context: All these typos have been introduced after b20180401,
which gives them only very little time to be discovered.

[Bug c/85665] New: Multiple typos in diagnostics

[roland.illig at gmx dot de]

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

Bug ID: 85665
   Summary: Multiple typos in diagnostics
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

Specify use soft floating point ABI which mean alias to -mabi=2.

Specify use soft floating point ABI which mean alias to -mabi=2fp+.

Specify a fpu configuration value from 0 to 7; 0-3 is as FPU spec says, and 4-7
is corresponding to 0-3.
a => an

Specify how many read/write ports for n9/n10 cores.  The value should be 3r2w
or 2r1w.
* double space
* the first sentence no verb

Always save $lp in the stack.
in => on

one field is bitfield while other is not
"" => a
"" => the

Disable FPU ISA, the ABI option must be enable '-mfloat-abi=soft'

'-mabi=2fp+' option only support when FPU available, must be enable
'-mext-fpu-sp' or '-mext-fpu-dp'

Known floating-point number of registers (for use with the -mconfig-fpu=
option):

this builtin function not support on the v3m toolchain

CCTL intrinsic function subtype out of range!
THERE IS AN EXCLAMATION MARK !!!ONEELEVEN

/* Note the cctl divide to 5 group and share the same name table.  */

In general:

* Please make sure that no diagnostic message ever ends with an exclamation
mark!!!

* Please make sure that every diagnostic that uses 'straight' "quotes" is
listed in a special white-list. All other diagnostics must only use
% quotes.

It's really simple to write a little program that checks the above things. As a
translator, I don't want check them each month again.

Especially in the month before a release, these changes should only be done
very carefully. I have the impression that there are more typos than in the
previous months.

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[harald at gigawatt dot nl]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #90 from Harald van Dijk  ---
Given how many years have passed I expect it's too late for anything to change,
but for completeness:

Assuming the stack is aligned breaks existing binaries compiled with old GCC
versions, and with GCC 8 this becomes far more visible. Minimal test case:
compile

  void exit(int);
  int main(void) { exit(0); }

with GCC 2.8, compile current glibc with GCC 8, and there will be a segfault in
glibc's __run_exit_handlers because GCC 2.8 never kept the stack
16-byte-aligned, but GCC 8 does now generate code which assumes it.

Yes, I've actually been running GCC 2.8-compiled binaries that have only now
become broken as a result of this. This is not hypothetical. For the moment,
I've rebuilt glibc with -mincoming-stack-boundary=2 to handle the problem well
enough for my current needs, but it's not a complete solution.

[Bug c++/82953] ICE in tree_check() ../../gcc/gcc/tree.h:3087

[slyfox at inbox dot ru]

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

--- Comment #2 from Sergei Trofimovich  ---
Does not crash on gcc-8. Still crashes on gcc-7.3.0.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #56 from John Paul Adrian Glaubitz  ---
Another issue:

In file included from ../.././gcc/config/powerpcspe/powerpcspe.h:1865:0,
 from ./tm.h:25,
 from ../.././gcc/genopinit.c:24:
../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:14: error: expected
‘}’ before ‘(’ token
 BU_P7_MISC_2 (DIVWE,  "divwe", CONST, dive_si)
  ^
../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:20: error: expected
‘)’ before ‘,’ token
 BU_P7_MISC_2 (DIVWE,  "divwe", CONST, dive_si)
^
../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:23: error: expected
unqualified-id before string constant
 BU_P7_MISC_2 (DIVWE,  "divwe", CONST, dive_si)
   ^~~
In file included from ./tm.h:25:0,
 from ../.././gcc/genopinit.c:24:
../.././gcc/config/powerpcspe/powerpcspe.h:1868:1: error: expected declaration
before ‘}’ token
 };
 ^
In file included from ../.././gcc/config/powerpcspe/powerpcspe.h:1865:0,
 from ./tm.h:25,
 from ../.././gcc/genattrtab.c:108:
../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:14: error: expected
‘}’ before ‘(’ token
 BU_P7_MISC_2 (DIVWE,  "divwe", CONST, dive_si)
  ^
../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:20: error: expected
‘)’ before ‘,’ token
 BU_P7_MISC_2 (DIVWE,  "divwe", CONST, dive_si)
^
../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:23: error: expected
unqualified-id before string constant
 BU_P7_MISC_2 (DIVWE,  "divwe", CONST, dive_si)
   ^~~
In file included from ./tm.h:25:0,
 from ../.././gcc/genattrtab.c:108:
../.././gcc/config/powerpcspe/powerpcspe.h:1868:1: error: expected declaration
before ‘}’ token
 };
 ^

Here I haven't figured out yet where the syntax error is. Either in
gcc/config/powerpcspe/powerpcspe.h or
gcc/config/powerpcspe/powerpcspe-builtin.def.

What I noticed that gcc/config/powerpcspe/powerpcspe-builtin.def has some stray
control sequences "^L" around line 212. Removing them did not change anything
though.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #55 from John Paul Adrian Glaubitz  ---
This seems to help:

diff --git a/gcc/config/powerpcspe/powerpcspe.md
b/gcc/config/powerpcspe/powerpcspe.md
index 746f2bd1ee3..2e08bcea2b5 100644
--- a/gcc/config/powerpcspe/powerpcspe.md
+++ b/gcc/config/powerpcspe/powerpcspe.md
@@ -4367,7 +4367,7 @@
   "#"
   [(set_attr "type" "store,store,load,load,*,*")
(set_attr "update" "yes")
-   (set_attr "indexed" "yes")]
+   (set_attr "indexed" "yes")])

 (define_split
   [(set (match_operand:TI2 0 "nonimmediate_operand" "")
@@ -4671,7 +4671,7 @@
  (clobber (reg:SI LR_REGNO))])]
   ""
   [(set_attr "type" "two")
-   (set (attr "length") (const_int 16))]
+   (set (attr "length") (const_int 16))])

 (define_insn_and_split "tls_gd_sysv"
   [(set (match_operand:TLSmode 0 "gpc_reg_operand" "=b")

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #54 from John Paul Adrian Glaubitz  ---
Just tried a native build with gcc from trunk plus the patch, fails due to an
apparent syntax error:

powerpc-linux-gnuspe-g++ -std=gnu++98   -g -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++
-static-libgcc  -no-pie -o build/genmatch \
build/genmatch.o ../../build-powerpc-linux-gnuspe/libcpp/libcpp.a
build/errors.o build/vec.o build/hash-table.o
../../build-powerpc-linux-gnuspe/libiberty/libiberty.a
build/genmddeps ../.././gcc/common.md
../.././gcc/config/powerpcspe/powerpcspe.md > tmp-mddeps
../.././gcc/config/powerpcspe/powerpcspe.md:4362:1: unterminated construct
make[3]: *** [Makefile:2306: s-mddeps] Error 1
make[3]: *** Waiting for unfinished jobs
rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gfdl.pod gcc.pod gcov-dump.pod
gcov-tool.pod
make[3]: Leaving directory '/srv/glaubitz/gcc/host-powerpc-linux-gnuspe/gcc'
make[2]: *** [Makefile:4624: all-stage1-gcc] Error 2
make[2]: Leaving directory '/srv/glaubitz/gcc'
make[1]: *** [Makefile:23666: stage1-bubble] Error 2
make[1]: Leaving directory '/srv/glaubitz/gcc'
make: *** [Makefile:953: all] Error 2

Configured with ./configure --build=powerpc-linux-gnuspe
--host=powerpc-linux-gnuspe --target=powerpc-linux-gnuspe --enable-obsolete
--with-cpu=8548 --enable-e500_double --with-long-double-128 
--disable-libphobos

[Bug c/85661] double comparison illegally statically reduced

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
See bug 323.

*** This bug has been marked as a duplicate of bug 323 ***

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||manuel.serrano at inria dot fr

--- Comment #204 from Andrew Pinski  ---
*** Bug 85661 has been marked as a duplicate of this bug. ***

[Bug c/85661] double comparison illegally statically reduced

[manuel.serrano at inria dot fr]

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

--- Comment #2 from manuel.serrano at inria dot fr ---
Dear Jakub,

Thank you very much for your useful answer. I was indeed ignorant of the
-fexcess-precision=fast option and as you suggested "-msse2 -mfpmath=sse"
solves the problem. I'm still puzzled why inserting a dummy printf changes
the behaviour of the double equality test. Is that expected?

[Bug c++/85659] [6/7/8/9 Regression] ICE with inline assembly inside virtual function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 44078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44078=edit
gcc8-pr85659.patch

Untested fix.

[Bug c++/85659] [6/7/8/9 Regression] ICE with inline assembly inside virtual function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-05
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.5
Summary|ICE with inline assembly|[6/7/8/9 Regression] ICE
   |inside virtual function |with inline assembly inside
   ||virtual function
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r232167, before it likely just emitted wrong code.
Short testcase:
struct S { S (); ~S (); int s; };

void
foo (S )
{
  asm volatile ("" : "+m,r" (s) : : "memory");
}

ICEs even with "+g" instead of "+m,r".

[Bug rtl-optimization/71878] ICE in cselib_record_set

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||6.3.0
 Resolution|--- |FIXED
  Known to fail|6.2.1   |6.2.0

--- Comment #6 from Thomas Preud'homme  ---
Backported to GCC 6 as r240257, therefore fixed on all currently supported
releases.

[Bug c/85664] New: Don't ask questions if tere's no way to answer

[gcc at mailed dot e4ward.com]

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

Bug ID: 85664
   Summary: Don't ask questions if tere's no way to answer
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at mailed dot e4ward.com
  Target Milestone: ---

(gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0)

How is the weather today?

All readers who are now irritated that they can't very well go and react to a
bug report solely to write about the weather, will realise that I should not
have asked about the weather somewhere where the reader can't answer me. This
is a standard for any publication: Don't ask the audience a question if they
have no way to reply.

Yet, every time I mistype a name - which with my co-ordination is a rather
frequent occurrence - GCC will now ask me: "; did you mean ‘’?".
I find offering an alternative an interesting concept. I haven't even looked up
yet how to switch it off as it's usually correct. (I do get the impression the
guesses are about the fairly obvious, which is when they are fairly obvious to
me as well, suggesting this doesn't add much.) But they are suggestions, not
questions.

A development environment can ask question i this situation because, when the
user replies by activating the confirm function, it can actually modify the
code it's holding. A stand-alone compiler should not ask questions.


Could this please be reworded?

Bye,
Mysha

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

  Known to work||8.1.0

--- Comment #15 from Thomas Preud'homme  ---
Fixed in r249224 and thus fixed on 8.1

[Bug sanitizer/85663] gcc-8.0.1 regression: sanitizer fails to build on mips-unknown-linux-gnu

[slyfox at inbox dot ru]

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

--- Comment #3 from Sergei Trofimovich  ---
Created attachment 44077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44077=edit
gcc-8.1.0-mips-o32-asan.patch

gcc-8.1.0-mips-o32-asan.patch is enough to get asan cross-compiled on o32 ABI.

[Bug c/85661] double comparison illegally statically reduced

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
If this is on i?86 32-bit, then most likely you just aren't taking into account
the extended precision and the default -fexcess-precision=fast mode.
So, either if you want excess precision, but require the C rules (and are using
C), you need to use -fexcess-precision=standard (default in strict C std
modes), or if you don't want excess precision, make sure you have SSE2 or later
hw and use -msse2 -mfpmath=sse.  In any case, that is a user error rather than
compiler bug.

[Bug sanitizer/85663] gcc-8.0.1 regression: sanitizer fails to build on mips-unknown-linux-gnu

[slyfox at inbox dot ru]

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

--- Comment #2 from Sergei Trofimovich  ---
> - FIRST_32_SECOND_64(144, 216);
> + FIRST_32_SECOND_64(160, 216);

I think mips has really 3 stat values:
  32 ABI: 144
 n32 ABI: 160
  64 ABI: 216

  $ cat a.c
  #include 
  #include 
  #include 

  int main() {
return sizeof(struct stat);
  }

  $ mips-unknown-linux-gnu-gcc -E -dM - 

[Bug c++/85662] [8/9 Regression] "error: non-constant condition for static assertion" from __builtin_offsetof in C++

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 44076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44076=edit
gcc8-pr85662.patch

Untested fix.

[Bug sanitizer/85663] gcc-8.0.1 regression: sanitizer fails to build on mips-unknown-linux-gnu

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  ---
GCC was configures as:

/tmp/portage/cross-mips-unknown-linux-gnu/gcc-8.1.0-r1/work/gcc-8.1.0/configure
--host=x86_64-pc-linux-gnu --target=mips-unknown-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/mips-unknown-linux-gnu/gcc-bin/8.1.0
--includedir=/usr/lib/gcc/mips-unknown-linux-gnu/8.1.0/include
--datadir=/usr/share/gcc-data/mips-unknown-linux-gnu/8.1.0
--mandir=/usr/share/gcc-data/mips-unknown-linux-gnu/8.1.0/man
--infodir=/usr/share/gcc-data/mips-unknown-linux-gnu/8.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/mips-unknown-linux-gnu/8.1.0/include/g++-v8
--with-python-dir=/share/gcc-data/mips-unknown-linux-gnu/8.1.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion=Gentoo 8.1.0-r1 p1.1 --disable-esp --enable-libstdcxx-time
--enable-poison-system-directories --with-sysroot=/usr/mips-unknown-linux-gnu
--disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-altivec --disable-fixed-point --with-abi=
--disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp
--disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto
--without-isl --enable-libsanitizer --enable-default-pie --enable-default-ssp

[Bug sanitizer/85663] New: gcc-8.0.1 regression: sanitizer fails to build on mips-unknown-linux-gnu

[slyfox at inbox dot ru]

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

Bug ID: 85663
   Summary: gcc-8.0.1 regression: sanitizer fails to build on
mips-unknown-linux-gnu
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

In file included from
/tmp/portage/cross-mips-unknown-linux-gnu/gcc-8.1.0-r1/work/gcc-8.1.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:20:
/tmp/portage/cross-mips-unknown-linux-gnu/gcc-8.1.0-r1/work/gcc-8.1.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:317:72:
error: size of array ‘assertion_failed__71’ is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
/tmp/portage/cross-mips-unknown-linux-gnu/gcc-8.1.0-r1/work/gcc-8.1.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:311:30:
note: in expansion of macro ‘IMPL_COMPILER_ASSERT’
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^~~~
/tmp/portage/cross-mips-unknown-linux-gnu/gcc-8.1.0-r1/work/gcc-8.1.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:71:1:
note: in expansion of macro ‘COMPILER_CHECK’
 COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct stat));
 ^~

I think it is caused by this patch:

https://github.com/gcc-mirror/gcc/commit/36093749ff955d9e8cf208b04724c3a1a2ac9b04

libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h

 #elif defined(__mips__)
   const unsigned struct_kernel_stat_sz =
  SANITIZER_ANDROID ? FIRST_32_SECOND_64(104, 128) :
- FIRST_32_SECOND_64(144, 216);
+ FIRST_32_SECOND_64(160, 216);

Your Weekly Breeze - May. 03 - May. 09

[Oasis Living Magazine]

This email newsletter was sent to you in graphical HTML format.
If you're seeing this version, your email program prefers plain text emails.
You can read the original version online:
https://ymlpsend3.com/zGWPof



Having problems viewing  Weekly Breeze Click here (
http://myoasisliving.com/weekly_breeze/weekly_breeze.php ).

TOP PICS

May 03 - May 09

-->

breeze@ myoasisliving.com for your chance to win aHanayen gift voucher
in Bawadi Mall worth Dh100. To win, simply email your complete name
and indicate Hanayenin the subject and you will qualify for a random
draw.

*If you win, you have 30 days to pick up your prize. If your prize is
not collected within 30 days of notification, it will be cancelled.
Participants who have won before are not eligible to win again within
90 days after winning

-->

The prince of horror
Author Joe Hill tells Oasis Living about stepping out of his
mega-famous father's shadow and making it on his own >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/e3c360f6517bdf2a233ca8cdcd99
)

Feeling supersonic
Thrill-seekers can now check one more item offtheir bucket list in
Ras Al Khaimah while travellingover 120 kilometres per hour on a
zipline >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/e3c360f6517bdf2a233ca8cdcd99
)

Into the future
The Tesla Model X P100D is the flagship in the pioneer brand's SUV
modelrange. So fast you could miss it, this might be the dawn of a new
era >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/e3c360f6517bdf2a233ca8cdcd99
)

Through the looking glass
As a frst-of-its-kind virtual reality experience launches in theUAE,
Oasis Living dares you try out the other side >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/e3c360f6517bdf2a233ca8cdcd99
)

Flying green
Being eco-conscious isn't just limited to choosing the right
products, it workswith tourism too. Here are eight sustainable
destinations to travel to this year >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/e3c360f6517bdf2a233ca8cdcd99
)

"AGENDA"

Wednesday

Mexican Buffet in The Amblers Restaurant, AESGC's Rugby Club, from
6.30 to 10.30pm: Dh49.

Sushi Night in The Palm Greens Restaurant, AESGC's Golf Club, from
6.30 to 10.30pm: Dh85.

Thursday

Thursday BBQ Buffet in The Palm Greens Restaurant at AESGC’s Golf
Club from 6.30 to 10.30pm: Dh199 per person with free-flow of one
selected beverage, Dh99 with free-flow of soft drinks - members
discount also applies on total bill.

Family Dining Night in AESGC's Rugby Club's Amblers Restaurant from
5.30pm with a 20 per cent discount for families.

"OTHER HIGHLIGHTS THIS WEEK"

15 May onwards

Sports Night in Danat Al Ain Resort's McGettigan’s.

Iftar at Danat Al Ain Resort's Arabesque from 7pm onwards: Dh110++
per person on weekdays, Dh129++ per on weekends. The hotel will also
be serving suhoor in their Ramadan tent from 8.30pm onwards: Dh30++
per person on weekdays, Dh50++ per on weekends.

Al Rikab Restaurant in AESGC's Equestrian Club will be serving iftar
from 7 to 9pm and then suhoor until 1am: Dh90 per person, Dh45 for
children aged seven to 12. Live entertainment available daily along
with a raffle draw.

Iftar buffet at Olive Tree in Aloft Al Ain: Dh120 per person on
weekdays, Dh140 per on weekends.

Iftar buffet at Elements in Hili Rayhaan by Rotana for Dh119 from
Saturdays to Wednesdays, and Dh139 on Thursdays and Fridays. Suhoor
available for Dh59.

Email us at bre...@myoasisliving.com and tell us what you like about
our Weekly Breeze. Let us know which stories you like to read about,
or what else you would like to see included. We appreciate all reader
feedback!

Forward weekly breeze to your friend (
http://www.myoasisliving.com/weekly_breeze/email_version/forward_to_friend_form.php?newsletter_version=html_weekly_breeze_may_03_may_09_2018_email=gcc-bugs@gcc.gnu.org
)

_
Unsubscribe / Change Profile: https://ymlpsend3.com/ugmwhmbhgsgmsbqmgyymggubuhw
Powered by YourMailingListProvider

[Bug target/85653] [nvptx] Work around subsequent bar.sync JIT/ptxas bug

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/85653] [nvptx] Work around subsequent bar.sync JIT/ptxas bug

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Tom de Vries  ---
Patch committed to trunk and backported to og7 branch, marking resolved-fixed.

[Bug c++/85662] [8/9 Regression] "error: non-constant condition for static assertion" from __builtin_offsetof in C++

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
In any case, I think the problem is related to the delayed folding, C++
constexpr handling not liking pointer constants and fold_offsetof_1 done as
pointer addition rather than integer addition.  With delayed folding and
fold_build_pointer_plus called by fold_offsetof_1 the nested expressions aren't
really folded.  We could easily fix it up by doing a cp_fold (together with
recursive cp_fold_r though, because cp_fold isn't fully recursive) on the
result of fold_offsetof in the C++ FE, that way we'd get a constant whenever
possible.
On the other side, we wouldn't then reject __builtin_offsetof used with not
valid constexpr expressions in the second argument (say out of bound array
access etc. subtracted from itself).
Say:
constexpr int a[5];
struct S { int b, c[5]; };
constexpr int d = __builtin_offsetof (S, c[([6] - [6]) + 2]);

Another possibility is in fold_offsetof_1, if we detect the TREE_CONSTANT base,
if it is a pointer typed INTEGER_CST, build corresponding sizetype INTEGER_CST
instead and use normal PLUS_EXPR folding (or do we actually want any folding at
all?) instead of fold_build_pointer_plus.

[Bug target/85653] [nvptx] Work around subsequent bar.sync JIT/ptxas bug

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Author: vries
Date: Sat May  5 07:56:21 2018
New Revision: 259967

URL: https://gcc.gnu.org/viewcvs?rev=259967=gcc=rev
Log:
[nvptx] Add workaround for subsequent bar.syncs

2018-05-05  Tom de Vries  

PR target/85653
* config/nvptx/nvptx.c (WORKAROUND_PTXJIT_BUG_3): Define.
(workaround_barsyncs): New function.
(nvptx_reorg): Use workaround_barsyncs.
* config/nvptx/nvptx.md (define_c_enum "unspecv"): Add UNSPECV_MEMBAR.
(define_expand "nvptx_membar_cta"): New define_expand.
(define_insn "*nvptx_membar_cta"): New insn.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c
trunk/gcc/config/nvptx/nvptx.md

[Bug c++/85662] [8/9 Regression] "error: non-constant condition for static assertion" from __builtin_offsetof in C++

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-05
 CC||jakub at gcc dot gnu.org
Version|unknown |8.0
   Target Milestone|--- |8.2
Summary|regression since 6: "error: |[8/9 Regression] "error:
   |non-constant condition for  |non-constant condition for
   |static assertion" from  |static assertion" from
   |__builtin_offsetof in C++   |__builtin_offsetof in C++
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Weird, I can only reproduce it starting with r247495 and can't reproduce with
gcc 7.
Better testcase that doesn't really depend on the actual structure layout and
sizes:
struct S { unsigned long x[31]; };
struct T { bool b; S f; };
static_assert (__builtin_offsetof (T, f.x[31 - 1]) == __builtin_offsetof (T,
f.x[30]), "");
Using 30 instead of 31-1 makes it go away, and the problem is that something
creates or keeps around 8 as pointer constant.

[Bug rtl-optimization/85645] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Started at r259672.