[Bug libgcc/66382] POWER8 Vector optimized implementation of __float128 (IEEE754 128-bit Binary Floating Point)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #6 from Segher Boessenkool  ---
Given the following program:

__float128 f(__float128 a, __float128 b) { return a*b; }

When compiled with:

gcc -Wall -W -O2 mulf.c -mfloat128 -mcpu=power8

you currently get (boring stuff cut out):

mflr 0
std 0,16(1)
stdu 1,-32(1)
bl __mulkf3
nop
addi 1,1,32
ld 0,16(1)
mtlr 0
blr

The task is to either optimise __mulkf3 to use vector math, or to
expand it inline even, where that make sense (this may more often
make sense with -ffast-math).

[Bug target/70052] [5/6 Regression] ICE compiling _Decimal128 test case

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

  Known to work|5.3.1   |4.9.4
Summary|ICE compiling _Decimal128   |[5/6 Regression] ICE
   |test case   |compiling _Decimal128 test
   ||case
  Known to fail||5.3.1

--- Comment #7 from Alan Modra  ---
Testing with current 5.3.1 shows it fails.

[Bug c++/70018] [4.9/5/6 Regression] Possible issue around IPO and C++ comdats discovered as pure/const

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #10 from Jason Merrill  ---
(In reply to Jan Hubicka from comment #9)
> To properly track possible loads/stores w/o any optimizations we probably
> need an info from Frontend, because we optimize out things prior
> gimplification. Jason, how feasible it is to do that?

The front end isn't tracking that information currently.  But I don't think it
does any optimizations that would cause this kind of issue, either.

[Bug bootstrap/70420] New: (Building GCC) mtune=native and internal compiler error at emit-rtl.c:1027

[xsetech at gmail dot com]

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

Bug ID: 70420
   Summary: (Building GCC) mtune=native and internal compiler
error at emit-rtl.c:1027
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xsetech at gmail dot com
  Target Milestone: ---

I'm compiling GCC 5.3.0 for OS X. Specifically compiling it for:

OS X El Capitan 10.11.3
Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz

The following command-line causes an internal compiler error:

CFLAGS_FOR_BUILD="-march=native -mtune=native"
CXXFLAGS_FOR_BUILD="-march=native -mtune=native" CFLAGS="-march=native
-mtune=native -mfpmath=sse" CPPFLAGS="-march=native -mtune=native
-mfpmath=sse" ../configure --prefix=/home/setech/Local/usr/local/
--with-mpc=/home/setech/Local/usr/local/
--with-gmp=/home/setech/Local/usr/local/
--with-mpfr=/home/setech/Local/usr/local/
--with-isl=/home/setech/Local/usr/local/ --enable-languages=c,c++ -v
&& make -j 3


Without the -mtune and -march options, make completes without verbal error.

The exact place of error is:

../../../../libquadmath/math/rem_pio2q.c:587:1: internal compiler
error: in gen_reg_rtx, at emit-rtl.c:1027


Some context in the compilation process:

xgcc: internal compiler error: Abort trap: 6 (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[6]: *** [math/rem_pio2q.lo] Error 1
make[5]: *** [all] Error 2
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[2]: *** [all] Error 2
make[1]: *** [all-target-libquadmath] Error 2
make[1]: *** Waiting for unfinished jobs


The host compiler is Xcode's version of GCC (LLVM). `gcc --version` returns:

Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.3.0
Thread model: posix


MPFR: 3.1.4
MPC: 1.0.3
GMP: 6.1.0
ISL: 0.16.1

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-27
 Ever confirmed|0   |1

--- Comment #11 from Oleg Endo  ---
I can confirm that attachment 38102 also fails on trunk without -mlra.

attachment 38104 compiles fine on trunk with -mlra, but fails on current GCC 5
branch.

[Bug driver/70419] New: descriptions of -fpic/-fPIC and -fpic/-fPIE aren't clear and contain syntax error

[britton.kerin at gmail dot com]

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

Bug ID: 70419
   Summary: descriptions of -fpic/-fPIC and -fpic/-fPIE aren't
clear and contain syntax error
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: britton.kerin at gmail dot com
  Target Milestone: ---

It's not clear if -fPIC can be used when compiling files which are going to be
linked into executables, or not.  The description of -fpic states that the
generated code is suitable for use in a shared library.  It doesn't say it
can't be used to link into an executable.  I believe that it can be and that
this is defined behavior.  However, because the -fpie/-fPIE options also exist,
the impression is created that -fpic/-fPIC cannot be used for executables.

I think the -fpic description should begin like this:

Generate position-independent code (PIC) suitable for use in a shared
library or executable, ...

I think the -fPIC option description should begin like this:

If supported for the target machine, emit position-independent code,
suitable for dynamic linking into executables or shared libraries, and
avoiding any limit...

The description of -fPIE contains a small syntax error.  The sentence

These options are similar to -fpic and -fPIC, but generated position
independent code can be only linked into executables.

is incorrect and should read:

These options are similar to -fpic and -fPIC, but generated position
independent code can only be linked into executables.


Here is how the -fpic/-fPIC and -fpic/-fPIE option descriptions currently read:

-fpic
Generate position-independent code (PIC) suitable for use in a shared
library, if supported for the target machine. Such code accesses all constant
addresses through a global offset table (GOT). The dynamic loader resolves the
GOT entries when the program starts (the dynamic loader is not part of GCC; it
is part of the operating system). If the GOT size for the linked executable
exceeds a machine-specific maximum size, you get an error message from the
linker indicating that -fpic does not work; in that case, recompile with -fPIC
instead. (These maximums are 8k on the SPARC and 32k on the m68k and RS/6000.
The x86 has no such limit.)

Position-independent code requires special support, and therefore works
only on certain machines. For the x86, GCC supports PIC for System V but not
for the Sun 386i. Code generated for the IBM RS/6000 is always
position-independent.

When this flag is set, the macros __pic__ and __PIC__ are defined to 1.
-fPIC
If supported for the target machine, emit position-independent code,
suitable for dynamic linking and avoiding any limit on the size of the global
offset table. This option makes a difference on the m68k, PowerPC and SPARC.

Position-independent code requires special support, and therefore works
only on certain machines.

When this flag is set, the macros __pic__ and __PIC__ are defined to 2.
-fpie
-fPIE
These options are similar to -fpic and -fPIC, but generated position
independent code can be only linked into executables. Usually these options are
used when -pie GCC option is used during linking.

-fpie and -fPIE both define the macros __pie__ and __PIE__. The macros have
the value 1 for -fpie and 2 for -fPIE.

[Bug c++/70417] New g++6 rejects previously valid code

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
> Is there something new in the C++ standards, or is this a g++ regression?

Since dy is a dependent template name you have to write

   return y.template dy();

So I think this is a case of earlier versions of gcc wrongly accepting this
code, and gcc 6 correctly rejecting it.

[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.

[sasho648 at gmail dot com]

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

--- Comment #4 from sasho648 at gmail dot com ---
The full ice message is:

test_bug_0.c: In function ‘main’:
test_bug_0.c:24:1: internal compiler error: Segmentation fault
0xb482ef crash_signal
../../gcc/gcc/toplev.c:335
0xbda96a get_frame_type
../../gcc/gcc/tree-nested.c:208
0xbda96a get_chain_decl
../../gcc/gcc/tree-nested.c:314
0xbddde9 get_chain_decl
../../gcc/gcc/tree-nested.c:826
0xbddde9 get_nonlocal_debug_decl
../../gcc/gcc/tree-nested.c:830
0xbde1d8 convert_nonlocal_reference_op
../../gcc/gcc/tree-nested.c:909
0xde8ac2 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/gcc/tree.c:11531
0x8d6960 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:201
0x8d6edc walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:584
0x8d70c8 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:51
0x8d6f82 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:594
0x8d70c8 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:51
0x8d6f82 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:594
0x8d70c8 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gcc/gimple-walk.c:51
0xbda371 walk_body
../../gcc/gcc/tree-nested.c:573
0xbda3c8 walk_function
../../gcc/gcc/tree-nested.c:584
0xbda3c8 walk_all_functions
../../gcc/gcc/tree-nested.c:649
0xbe2562 lower_nested_functions(tree_node*)
../../gcc/gcc/tree-nested.c:3133
0x7738b6 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:631
0x776e33 analyze_functions
../../gcc/gcc/cgraphunit.c:1086

[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.

[sasho648 at gmail dot com]

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

--- Comment #3 from sasho648 at gmail dot com ---
currently *is* working fine and as expected when the function is not nested

[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.

[sasho648 at gmail dot com]

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

--- Comment #2 from sasho648 at gmail dot com ---
Must be noted that such code must be valid and actually currently working fine
and as expected when the function is not nested. Eg.:

#include 

extern void fp(int a, const struct {int _[a];} *b)
{
for(size_t i=0; i < sizeof(b->_) / sizeof(b->_[0]); ++i)
printf("%d ", b->_[i]);

 printf("%zu\n", sizeof(b->_));
}

void f(int a, struct {int _[a];} b)
{
for(size_t i=0; i < sizeof(b._) / sizeof(b._[0]); ++i) //modify while
retaining the passed argument
b._[i] *= 9;

fp(a, ); //prints 81 as many times as 'a'
}

main(int n, char **pp)
{
scanf("%i", );

struct {int _[n];} tmp;

for(int i; i < n; ++i)
tmp._[i] = 9;

((void (*)(int a, __typeof__(tmp) b))f)(n, tmp); //cast required as VM
types aren't equal in the case

fp(n, ); //should print 9 as many times as 'n'
}

[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.

[sasho648 at gmail dot com]

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

sasho648 at gmail dot com changed:

   What|Removed |Added

Summary|VM structure type specifier |VM structure type specifier
   |in  list of parameter   |in list of parameter
   |declarations function   |declarations within nested
   |definition  |function definition ices.

--- Comment #1 from sasho648 at gmail dot com ---
Consider this self-contained example:

main() 
{
void func(int a, struct {int _[a];} v) {}
}

When compiled it Ices both on GCC 6.0 and GCC 4.8.2 .

[Bug c/70418] New: VM structure type specifier in list of parameter declarations function definition

[sasho648 at gmail dot com]

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

Bug ID: 70418
   Summary: VM structure type specifier in  list of parameter
declarations function definition
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sasho648 at gmail dot com
  Target Milestone: ---

[Bug c++/70275] -w disables all -Werror flags

[kevin-tucker at cox dot net]

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

--- Comment #3 from Kevin Tucker  ---
(In reply to Manuel López-Ibáñez from comment #2)
> I'm not sure if this is desired, but changing it is not a huge amount of
> work: One just needs to move the check for
> 
>   /* Give preference to being able to inhibit warnings, before they
>  get reclassified to something else.  */
>   if ((diagnostic->kind == DK_WARNING || diagnostic->kind == DK_PEDWARN)
>   && !diagnostic_report_warnings_p (context, location))
> return false;
> 
> after they get reclassified within diagnostic.c:
> 
> diagnostic_report_diagnostic (diagnostic_context *context,
>   diagnostic_info *diagnostic)
> 
> 
> See
> https://gcc.gnu.org/wiki/GettingStarted#Basics:
> _Contributing_to_GCC_in_10_easy_steps

I'm new to this.  How is is determined if this is a desired change or not?

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
Created attachment 38104
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38104=edit
Preprocessed source for sprintf.c when building with -mlra

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #9 from John Paul Adrian Glaubitz  ---
Hmm, unfortunately, passing -mlra for the whole build is apparently not a good
idea:

sprintf.c: In function 'rb_str_format':
sprintf.c:1217:1: error: unable to find a register to spill
 }
 ^
sprintf.c:1217:1: error: this is the insn:
(insn 17497 17498 3766 469 (set (reg:QI 3766)
(reg:QI 3767)) /usr/include/sh4-linux-gnu/bits/string3.h:53 273
{*movqi}
 (expr_list:REG_DEAD (reg:QI 3767)
(nil)))
sprintf.c:1217: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccbUbdGW.out file, please attach this to
your bugreport.

Full build log in [1]. Preprocessed source ccbUbdGW.out is following shortly.

Adrian

> [1] 
> https://people.debian.org/~glaubitz/ruby2.3_2.3.0-5_sh4-20160326-1814.build

[Bug c++/70417] New: New g++6 rejects previously valid code

[jengelh at inai dot de]

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

Bug ID: 70417
   Summary: New g++6 rejects previously valid code
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
CC: rguenther at suse dot de
  Target Milestone: ---

---8<---
template struct ref {
template ref dy() const { return ref(); }
};
template ref dy(ref y) {
return y.dy();
}
--->8---

gcc version 6.0.0 20160324 (experimental) [trunk revision 234449] (SUSE Linux) 
produces:

t.cpp: In function ‘ref dy(ref)’:
t.cpp:5:15: error: expected primary-expression before ‘>’ token
  return y.dy();
   ^
t.cpp:5:17: error: expected primary-expression before ‘)’ token
  return y.dy();
 ^

Prior g++ versions, including
* gcc version 4.8.5 (SUSE Linux)
* gcc version 5.3.1 20160301 [gcc-5-branch revision 233849] (SUSE Linux) 
* and some un-rememberable g++6 "from last month or so"
all accepted the code. Is there something new in the C++ standards, or is this
a g++ regression?

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #8 from John Paul Adrian Glaubitz  ---
Ok, I have added -save-temps to the command line which created both assembly
output as well as the preprocessed output.

Adrian

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
Created attachment 38103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38103=edit
Assembly output for vm.c

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #6 from John Paul Adrian Glaubitz  ---
Created attachment 38102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38102=edit
Preprocessed source for vm.c

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #3)
> (In reply to Oleg Endo from comment #1)
> > You could try to compile the package with -mlra and see if it helps.
> 
> I'm giving that a try now and will report back shortly.

Ok, first feedback, -mlra helps indeed:

(sid-sh4-sbuild)root@z6:/build/ruby2.3-_2wIP6/ruby2.3-2.3.0# gcc -mlra -mieee
-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-D_FORTIFY_SOURCE=2 -fstack-protector -fno-strict-overflow -fvisibility=hidden
-DRUBY_EXPORT -Wdate-time -D_FORTIFY_SOURCE=2   -I.
-I.ext/include/sh4-linux-gnu -I./include -I. -o vm.o -c vm.c
(sid-sh4-sbuild)root@z6:/build/ruby2.3-_2wIP6/ruby2.3-2.3.0# ls -l vm.o
-rw-r--r-- 1 root root 1364948 Mar 26 16:45 vm.o
(sid-sh4-sbuild)root@z6:/build/ruby2.3-_2wIP6/ruby2.3-2.3.0#

I'm creating the intermediate files now, just a second.

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

[bernd.edlinger at hotmail dot de]

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

--- Comment #24 from Bernd Edlinger  ---
Created attachment 38101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38101=edit
possible patch

Hi,

this is a patch that fixes the check-mpc issue and
fixes gmp-6.1.0 in-tree

The reason for the mpc check problem is that mpfr
changed the place where the libmpfr.la is around.

It was moved from mpfr/.lib to mpfr/src/.lib
and of course, we override LDFLAGS with "-static-libstdc++ -static-libgcc"
while mpc would normally use LDFLAGS="-L.../gcc-build/./gmp/.libs
-L.../gcc-build/./mpfr/.libs -static-libstdc++ -static-libgcc"

That used to work because we also add mpfr/.libs to the
LD_LIBRARY_PATH but we have foggot to ad mpfr/src/.lib
which my patch does, to fix the check-mpc make target.


Bernd.

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #3)
> 
> > What constraints does DTRACE_PROBE4 macro have?
> 
> I'm not sure however where DTRACE_PROBE4 is defined. Is that specific for
> the build environment?
> 

The easiest way -- as always -- is to compile the thing with -save-temps and
get the .i or .ii files.

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #1)
> You could try to compile the package with -mlra and see if it helps.

I'm giving that a try now and will report back shortly.

(In reply to Rich Felker from comment #2)
> Since it's non-obvious where the relevant macros are defined, where that 
> __asm__ statement comes from, and what its operands are, it would be really 
> helpful if you or someone from the Ruby side could point it out

From the Ruby people, I have received so far only this comment:

> What constraints does DTRACE_PROBE4 macro have?

I'm not sure however where DTRACE_PROBE4 is defined. Is that specific for the
build environment?

Adrian

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[bugdal at aerifal dot cx]

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

--- Comment #2 from Rich Felker  ---
Since it's non-obvious where the relevant macros are defined, where that
__asm__ statement comes from, and what its operands are, it would be really
helpful if you or someone from the Ruby side could point it out; that would
make it a lot easier to determine whether this is definitely a Ruby bug or
potentially a GCC bug.

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
You could try to compile the package with -mlra and see if it helps.

[Bug target/70416] New: [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 70416
   Summary: [SH]: error: 'asm' operand requires impossible reload
when building ruby2.3
   Product: gcc
   Version: 5.3.1
   URL: https://buildd.debian.org/status/fetch.php?pkg=ruby2.3
=sh4=2.3.0-2=1455247013
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: bugdal at aerifal dot cx, kkojima at gcc dot gnu.org,
olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Hi!

We're currently having issues building ruby2.3 on Debian sh4:

gcc -mieee -g -O2 -fstack-protector-strong -Wformat -Werror=format-security
-fPIC  -D_FORTIFY_SOURCE=2 -fstack-protector -fno-strict-overflow
-fvisibility=hidden -DRUBY_EXPORT -Wdate-time -D_FORTIFY_SOURCE=2   -I.
-I.ext/include/sh4-linux-gnu -I./include -I. -o vm.o -c vm.c
In file included from probes.h:10:0,
 from vm.c:23:
vm_exec.c: In function 'vm_exec_core':
probes.h:21:1: error: 'asm' operand requires impossible reload
 DTRACE_PROBE4 (ruby, method__entry, arg1, arg2, arg3, arg4)
 ^
(...)
insns.def:825:13: note: in expansion of macro 'RUBY_DTRACE_CMETHOD_RETURN_HOOK'
 RUBY_DTRACE_CMETHOD_RETURN_HOOK(th, 0, 0);
 ^
Makefile:375: recipe for target 'vm.o' failed
make[2]: *** [vm.o] Error 1

I have initially suspected this to be a problem in ruby2.3 itself [1] as
ruby2.2 built without any problems. However, after doing some research, it
seems that the error message "'asm' operand requires impossible reload" usually
indicates a problem within gcc and I'm therefore opening a bug here.

I have created a tarball which contains the build root for ruby2.3 after the
build failed, so all the object files are still there [2].

Adrian

> [1] https://bugs.ruby-lang.org/issues/12120
> [2] https://people.debian.org/~glaubitz/ruby2.3-sh4-build.tgz

[Bug c/70412] -Wswitch and functions that can only return a small set of values

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Isabella from comment #0)
> This is more of a question than a bug report: does that code need a default
> case?  I think it shouldn't, it handles all the possible return values...

But the warning does not know this because it doesn't look into func() and
analysing what func() returns may become very complex. It would be nice if it
would at least try, but that is way beyond of current GCC capabilities.

> Is that warning useful?

Imagine somebody changes func() to return c.

[Bug c++/70275] -w disables all -Werror flags

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
I'm not sure if this is desired, but changing it is not a huge amount of work:
One just needs to move the check for

  /* Give preference to being able to inhibit warnings, before they
 get reclassified to something else.  */
  if ((diagnostic->kind == DK_WARNING || diagnostic->kind == DK_PEDWARN)
  && !diagnostic_report_warnings_p (context, location))
return false;

after they get reclassified within diagnostic.c:

diagnostic_report_diagnostic (diagnostic_context *context,
  diagnostic_info *diagnostic)


See
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

[Bug ipa/70366] [6 Regression] chromium fails to build with LTO due to segfault in ipa-inline-transform.c:inline_call

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Sat Mar 26 10:08:47 2016
New Revision: 234490

URL: https://gcc.gnu.org/viewcvs?rev=234490=gcc=rev
Log:
2016-03-26  Richard Biener  
Prathamesh Kulkarni  

PR ipa/70366
* ipa-inline-transform.c (inline_call): Pass opts_for_fn (to->decl)
instead of
TREE_OPTIMIZATION (DECL_FUNCTION_SPECIFIC_OPTIMIZATION (to->decl))
as 2nd argument to cl_optimization_restore().


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-transform.c

[Bug testsuite/70356] gcc.target/i386/avx-vextractf128-256-5.c FAILs

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-26
  Component|target  |testsuite
   Target Milestone|--- |5.4
 Ever confirmed|0   |1

--- Comment #6 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)
> I guess we need to wait on Kirill for the reason why the test has been added.
> It could be that it has been assembled badly, and then dg-do assemble is
> completely reasonable.  Or it could be added for other reasons.

Some mailing list archaeology revealed [1] that dg-do assemble is intended.

The patch from Comment #2 is OK, please also forward-port the test to mainline.

[1] https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02196.html

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[dominiq at lps dot ens.fr]

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

--- Comment #21 from Dominique d'Humieres  ---
> Nice work!

Unfortunately not finished yet!-(

program fmt
  implicit none
  real*4 y
  character(45) :: fmtstr
  integer :: p,w,d
  y = 643.125
  d=2
  w=18
  do p=-8,7
write(fmtstr,"(g0,g0,g0,g0,g0,g0,g0,g0)") '(a,','"
y=",ru,',p,'pf',w,'.',d,')'
write(*,fmtstr) fmtstr(10:scan(fmtstr,')')-1), y
  end do
end program fmt

gives

ru,-8pf18.2 y=  1.00
ru,-7pf18.2 y=  1.00
ru,-6pf18.2 y=  1.00
ru,-5pf18.2 y=  0.01
...

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[kugan at gcc dot gnu.org]

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

--- Comment #10 from kugan at gcc dot gnu.org ---
I am looking into it.  -mcpu=arm966e-s does not uses the
TARGET_NEW_GENERIC_COSTS. i.e, the rtx costs setup by the back-end might not be
optimal.

[Bug fortran/69043] Trying to include a directory causes an infinite loop

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jerry DeLisle  ---
Closing