[Bug c++/69635] 4x increase of build time [4.9 -> 6.0]

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Did you build gcc6 with --enable-checking=release ?

[Bug c++/69638] New: array out of bounds access accepted in constexpr function invocation

[msebor at gcc dot gnu.org]

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

Bug ID: 69638
   Summary: array out of bounds access accepted in constexpr
function invocation
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC silently accepts the following invalid definitions and invocations of the
constexpr functions.  I believe the program is invalid/ill-formed (and requires
a diagnostic) because the constexpr functions would have undefined behavior and
thus do not produce core constant expressions.

The same functions are rejected as expected when A is replaced with int. 
(Clang rejects them either way.)

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra
-Wpedantic -std=c++14 -xc++ t.c
struct A {
  constexpr A (int = 0) { }
  constexpr operator int () const { return 0; }
};

constexpr int foo () {
  A a [3] = { 1, 2, 3 };
  return a [99];
}

struct B { unsigned b: foo () + 1; };

#if __GNUG__ > 5
  // GCC 5 fails on this because of either 69509 or 69516
constexpr int bar (int n) {
  A a [n] = { 1, 2, 3 };
  return a [99];
}

struct C {
unsigned c: bar (1) + 1;
};

#endif
t.c: In function ‘constexpr int bar(int)’:
t.c:16:9: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
   A a [n] = { 1, 2, 3 };
 ^
$

Turnoff prefetching for -march=znver1

[Stepanyan, Victoria]

Hi Maintainers,

This patch disables prefetching for -march=znver1 which is turned on by default.

gcc/ChangeLog:

2016-02-02 Victoria Stepanyan 

* gcc/config/i386/x86-tune.def: Disable default prefetching for 
-march=znver1

Ok for trunk?

Victoria

--- a/gcc/config/i386/x86-tune.def
+++ b/gcc/config/i386/x86-tune.def
@@ -218,7 +218,7 @@ DEF_TUNE (X86_TUNE_FOUR_JUMP_LIMIT, "four_jump_limit",
at -O3.  For the moment, the prefetching seems badly tuned for Intel
chips.  */
DEF_TUNE (X86_TUNE_SOFTWARE_PREFETCHING_BENEFICIAL, 
"software_prefetching_beneficial",
-  m_K6_GEODE | m_AMD_MULTIPLE)
+  m_K6_GEODE | m_ATHLON_K8 | m_AMDFAM10 | m_BDVER | m_BTVER)

/* X86_TUNE_LCP_STALL: Avoid an expensive length-changing prefix stall
on 16-bit immediate moves into memory on Core2 and Corei7.  */

[Bug hsa/69568] Invalid HSAIL opcode when using builtin vector

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-02
  Component|libgomp |hsa
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Jambor  ---
Confirmed and mine.

[Bug fortran/69423] [6 Regression] Invalid optimization with deferred-length character

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Dear Anthony,

In reply to your email message, this one is high on my list of PRs to fix. A
workaround, which could be permanent, is:

program tester
character(LEN=:), allocatable :: S

S= test(2)
print *, S

contains

function test(alen) result(rtest)
character(LEN=:), allocatable :: rtest
integer alen, i

do i = alen, 1, -1
rtest = 'test'
exit
end do

!This line prints nothing when compiled with -O1 and higher
print *, rtest

end function test


end program tester

At the moment, I cannot see why an explicit function result should be
different. The code displayed with -fdump-tree-original looks to be the same!

I have set things up in previous patches such that the string length is an
indirect reference to that in the caller. Apparently, in the original testcase
the reference is broken. The memory allocated to 'test' is correct but the
string length remains zero. Even weirder is that this is specific to DO
blocks

That said, if Andre can see a way to fix it, I would be more than happy to let
him do it :-)

Cheers

Paul

Re: [PATCH] s390: Add -fsplit-stack support

[Ulrich Weigand]

Marcin Kościelnicki wrote:

> Here we go.  I've also removed the "see below", since I don't really
> see anything below...

The "see below" refers to this code (which I agree isn't really obvious):

  if (TARGET_TPF_PROFILING)
{
  /* Generate a BAS instruction to serve as a function
 entry intercept to facilitate the use of tracing
 algorithms located at the branch target.  */
  emit_insn (gen_prologue_tpf ());

What is not explicitly called out here is that this tracing function
actually refers to some hard registers, in particular r14, and assumes
they still have the original contents as at function entry.

That is why the prolog code avoid using r14 as temporary if the TPF
tracing mechanism is in use.  Now I think this doesn't apply to r12,
so this part of your patch should still be fine.  (In addition, TPF
is not going to support split stacks --or indeed the Go language--
anyway, so it doesn't really matter all that much.)


I do have two other issues; sorry for bringing those up again although
they've been discussed up in the past, but I still think we can find
some improvements here ...

The first is the question Andreas brought up, why we need the extra
set of insns introduced by s390_reorg.  I think this may really have
been necessary for the ESA case where data elements had to be intermixed
into code at a specific location.  But since we no longer support ESA,
we now just have a data block that can be placed anywhere.  For example,
we could just have an insn (at any point in the prolog stream) that
simply emits the full data block during final output, along the lines of
(note: needs to be updated for SImode vs. DImode.):

(define_insn "split_stack_data"
  [(unspec_volatile [(match_operand 0 "bras_sym_operand" "X")
 (match_operand 1 "bras_sym_operand" "X")
 (match_operand 2 "consttable_operand" "X")
 (match_operand 3 "consttable_operand" "X")]
UNSPECV_SPLIT_STACK_DATA)]
  ""
{
  switch_to_section (targetm.asm_out.function_rodata_section
  (current_function_decl));

  output_asm_insn (\".align 3", operands);
  (*targetm.asm_out.internal_label) (asm_out_file, \"L\",
 CODE_LABEL_NUMBER (operands[0]));
  output_asm_insn (\".quad %2\", operands);
  output_asm_insn (\".quad %3\", operands);
  output_asm_insn (\".quad %1-%0\", operands);

  switch_to_section (current_function_section ());
  return "";
}
  [(set_attr "length" "0")])

Or possibly even cleaner, we can simply define the data block at the
tree level as if it were an initialized global variable of a certain
struct type, and just leave it to common code to emit it as usual.

Then we just have the code bits, but I don't really see much
difference between the split_stack_call and split_stack_sibcall
patterns (apart from the data block), so if code flow is OK with
the former insns, it should be OK with the latter too ..

[ Or else, if there *are* code flow issues, the other alternative
would be to emit the full call sequence, code and data, from a
single insn pattern during final output.  This might have the extra
benefit that the assembler sequence is fully fixed, and thus easier
to detect in the linker.  ]

Getting rid of the extra transformation in s390_reorg would not
just remove a bunch of code from the back-end (always good!),
it would also speed up compile time a bit.


The second issue I'm still not sure about is the magic nop marker
for frameless functions.  In an earlier mail you wrote:

> Both currently supported 
> architectures always emit split-stack code on every function.

At least for rs6000 this doesn't appear to be true; in
rs6000_expand_split_stack_prologue we have:

  if (!info->push_p)
return;

so it does nothing for frameless routines.

Now on i386 we do indeed generate code for frameless routines;
in fact, the *same* full stack check is generated as for any
other routine.  Now I'm wondering: is there are reason why
this check would be necessary (and there's simply a bug in
the rs6000 implementation)?  Then we obviously should do the
same on s390.

On the other hand, if rs6000 works fine *without* any code
in frameless routines, why wouldn't that work for s390 too?

Emitting a nop (that is always executed) still looks weird to me.


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  ---
Joseph, is the patch proposed in the original description okay as fix for stage
4 or you want a __NO_FPRS__ addressed?

[Bug target/69639] New: [6 Regression] FAIL: gcc.c-torture/compile/limits-exprparen.c

[danglin at gcc dot gnu.org]

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

Bug ID: 69639
   Summary: [6 Regression] FAIL:
gcc.c-torture/compile/limits-exprparen.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

At all optimizations:

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ 
-f
no-diagnostics-show-caret -fdiagnostics-color=never-Os  -w -c   -o
limits-en
umconst.o
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/limits-enumconst
.c(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-fno-diagnostics
-show-caret -fdiagnostics-color=never -Os -w -c -o limits-enumconst.o
/test/gnu/
gcc/gcc/gcc/testsuite/gcc.c-torture/compile/limits-enumconst.c
PASS: gcc.c-torture/compile/limits-enumconst.c   -Os  (test for excess errors)
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ 
-f
no-diagnostics-show-caret -fdiagnostics-color=never-O0  -w -c   -o
limits-ex
prparen.o
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/limits-exprparen
.c(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-fno-diagnostics
-show-caret -fdiagnostics-color=never -O0 -w -c -o limits-exprparen.o
/test/gnu/
gcc/gcc/gcc/testsuite/gcc.c-torture/compile/limits-exprparen.c
^M
Pid 22263 received a SIGSEGV for stack growth filure.^M
Possible causes: insufficient memory or swap space,^M
or stack size exceeded maxssiz. ^M
xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,

-bash-4.3$ ulimit -s
16384

Only seen on 32-bit hpux target.  64-bit and linux are okay.

New template for 'cpplib' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'cpplib' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/cpplib-6.1-b20160131.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160131/gcc-6-20160131.tar.bz2

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PING] Add new mexecute-only arm option.

[Sandra Loosemore]

On 02/02/2016 02:06 AM, mickael guene wrote:

Hi All,

  Ping for following thread :

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01968.html
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01969.html
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01970.html


Two comments:

(1) MIPS has had a similar option for quite some time called 
-mcode-readable=.  It might be less confusing to use a similar name for 
the ARM option with the similar reversed sense to -mexecute-only, even 
if it doesn't need to be a tristate flag like for MIPS.


(2) I suggest changing the help string for the command line option


+
+mexecute-only
+Target Report Var(target_execute_only) Init(0)
+Forbid load into text sections.


to use the same wording as the documentation in the manual:


+@item -mexecute-only
+@opindex mexecute-only
+Disable read memory access inside code sections.  Only code fetching is
+allowed.
+This option is off by default.
+


Or at least, "load into text sections" is confusing.  (You load *from* 
the text section, not *into* it, right?)


-Sandra

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/gcc-6.1-b20160131.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160131/gcc-6-20160131.tar.bz2

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Bug c++/69635] 4x increase of build time [4.9 -> 6.0]

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
You can speed up the build time by using -flto=.

With -flto=4 it compiles in ~5 minutes on my machine with gcc-6
(checking=release).

Closing as invalid.

Re: [Patch, fortran, pr67451, gcc-5, v1] [5/6 Regression] ICE with sourced allocation from coarray

[Paul Richard Thomas]

Hi Andre,

This one looks good too. As every day goes by, I see more and more why
Tobias was so keen to incorporate all objects into a single descriptor
type :-)

OK for 5-branch.

Thanks for both the patches

Paul

On 1 February 2016 at 13:34, Andre Vehreschild  wrote:
> Oh, well, now with attachments. I am sorry.
>
> - Andre
>
> On Mon, 1 Feb 2016 13:20:24 +0100
> Andre Vehreschild  wrote:
>
>> Hi all,
>>
>> here is the backport of the patch for pr67451 for gcc-5. Because the
>> structure of the allocate() in trunk is quite different the patch looks
>> somewhat different, too, but essentially does the same.
>>
>> Bootstrapped and regtests ok on x86_64-linux-gnu/F23.
>>
>> Ok for gcc-5-branch?
>>
>> Here is the link to the mainline patch:
>> https://gcc.gnu.org/ml/fortran/2016-01/msg00093.html
>>
>> Regards,
>>   Andre
>>
>> On Fri, 29 Jan 2016 19:17:24 +0100
>> Andre Vehreschild  wrote:
>>
>> > Hi all,
>> >
>> > attached is a patch to fix a regression in current gfortran when a
>> > coarray is used in the source=-expression of an allocate(). The ICE was
>> > caused by the class information, i.e., _vptr and so on, not at the
>> > expected place. The patch fixes this.
>> >
>> > The patch also fixes pr69418, which I will flag as a duplicate in a
>> > second.
>> >
>> > Bootstrapped and regtested ok on x86_64-linux-gnu/F23.
>> >
>> > Ok for trunk?
>> >
>> > Backport to gcc-5 is pending, albeit more difficult, because the
>> > allocate() implementation on 5 is not as advanced the one in 6.
>> >
>> > Regards,
>> > Andre
>>
>>
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

[Bug fortran/69636] New: ICE(s) on using option -fmodule-private

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69636
   Summary: ICE(s) on using option -fmodule-private
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

A validation run with option -fmodule-private exposes a few problems
when running on test files from ./gcc/testsuite/gfortran.dg/


$ gfortran-6 -fmodule-private -c function_kinds_3.f90
f951: internal compiler error: in gfc_convert_chartype, at
fortran/intrinsic.c:4812


$ gfortran-6 -fmodule-private -c entry_16.f90
f951: internal compiler error: Unable to find symbol ‘cx_radc’


$ gfortran-6 -fmodule-private -c associate_6.f03
f951: internal compiler error: find_array_spec(): Missing spec


And, respectively :
f951: internal compiler error: Segmentation fault

$ gfortran-6 -fmodule-private -c derived_external_function_1.f90
$ gfortran-6 -fmodule-private -c derived_function_interface_1.f90
$ gfortran-6 -fmodule-private -c function_kinds_1.f90
$ gfortran-6 -fmodule-private -c function_types_2.f90
$ gfortran-6 -fmodule-private -c typebound_operator_9.f03

Re: [PATCH] s390: Add -fsplit-stack support

[Marcin Kościelnicki]

On 02/02/16 19:33, Ulrich Weigand wrote:

Marcin Kościelnicki wrote:


Here we go.  I've also removed the "see below", since I don't really
see anything below...


The "see below" refers to this code (which I agree isn't really obvious):

   if (TARGET_TPF_PROFILING)
 {
   /* Generate a BAS instruction to serve as a function
  entry intercept to facilitate the use of tracing
  algorithms located at the branch target.  */
   emit_insn (gen_prologue_tpf ());

What is not explicitly called out here is that this tracing function
actually refers to some hard registers, in particular r14, and assumes
they still have the original contents as at function entry.

That is why the prolog code avoid using r14 as temporary if the TPF
tracing mechanism is in use.  Now I think this doesn't apply to r12,
so this part of your patch should still be fine.  (In addition, TPF
is not going to support split stacks --or indeed the Go language--
anyway, so it doesn't really matter all that much.)


Very well, I'll improve the comment.



I do have two other issues; sorry for bringing those up again although
they've been discussed up in the past, but I still think we can find
some improvements here ...

The first is the question Andreas brought up, why we need the extra
set of insns introduced by s390_reorg.  I think this may really have
been necessary for the ESA case where data elements had to be intermixed
into code at a specific location.  But since we no longer support ESA,
we now just have a data block that can be placed anywhere.  For example,
we could just have an insn (at any point in the prolog stream) that
simply emits the full data block during final output, along the lines of
(note: needs to be updated for SImode vs. DImode.):

(define_insn "split_stack_data"
   [(unspec_volatile [(match_operand 0 "bras_sym_operand" "X")
  (match_operand 1 "bras_sym_operand" "X")
  (match_operand 2 "consttable_operand" "X")
  (match_operand 3 "consttable_operand" "X")]
 UNSPECV_SPLIT_STACK_DATA)]
   ""
{
   switch_to_section (targetm.asm_out.function_rodata_section
   (current_function_decl));

   output_asm_insn (\".align 3", operands);
   (*targetm.asm_out.internal_label) (asm_out_file, \"L\",
  CODE_LABEL_NUMBER (operands[0]));
   output_asm_insn (\".quad %2\", operands);
   output_asm_insn (\".quad %3\", operands);
   output_asm_insn (\".quad %1-%0\", operands);

   switch_to_section (current_function_section ());
   return "";
}
   [(set_attr "length" "0")])

Or possibly even cleaner, we can simply define the data block at the
tree level as if it were an initialized global variable of a certain
struct type, and just leave it to common code to emit it as usual.

Then we just have the code bits, but I don't really see much
difference between the split_stack_call and split_stack_sibcall
patterns (apart from the data block), so if code flow is OK with
the former insns, it should be OK with the latter too ..

[ Or else, if there *are* code flow issues, the other alternative
would be to emit the full call sequence, code and data, from a
single insn pattern during final output.  This might have the extra
benefit that the assembler sequence is fully fixed, and thus easier
to detect in the linker.  ]

Getting rid of the extra transformation in s390_reorg would not
just remove a bunch of code from the back-end (always good!),
it would also speed up compile time a bit.


When I wasn't using reorg, I had problems with gcc deleting the label in 
.rodata, since it wasn't used by any jump instruction.  I guess having a 
whole-block instruction that emits the label on its own should solve the 
issue, though - let's try that.



The second issue I'm still not sure about is the magic nop marker
for frameless functions.  In an earlier mail you wrote:


Both currently supported
architectures always emit split-stack code on every function.


At least for rs6000 this doesn't appear to be true; in
rs6000_expand_split_stack_prologue we have:

   if (!info->push_p)
 return;

so it does nothing for frameless routines.

Now on i386 we do indeed generate code for frameless routines;
in fact, the *same* full stack check is generated as for any
other routine.  Now I'm wondering: is there are reason why
this check would be necessary (and there's simply a bug in
the rs6000 implementation)?  Then we obviously should do the
same on s390.


Try that on powerpc64(le):

$ cat a.c
#include 

void f(void) {
}

typedef void (*fptr)(void);

fptr g(void);

int main() {
printf("%p\n", g());
}

$ cat b.c
void f(void);

typedef void (*fptr)(void);

fptr g(void) {
return f;
}

$ gcc -O3 -fsplit-stack -c b.c
$ gcc -O3 -c a.c
$ gcc a.o b.o -fuse-ld=gold

I don't have a recent enough gcc for powerpc, but from what I've seen in 
the code, this should explode with a linker error.


Of course, 

[Bug c++/69637] New: ICE on an invalid bit-field with template name for width

[msebor at gcc dot gnu.org]

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

Bug ID: 69637
   Summary: ICE on an invalid bit-field with template name for
width
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

I ran into the following ICE when I accidentally put the ", 3" just past the
template argument list (instead of typing "foo()"):

  template 
  constexpr int foo () { return N; }

  struct B { unsigned c: foo, 3(); };

The problem can be further reduced to the following (invalid) test case.  All
supported versions of GCC fail similarly.

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra
-Wpedantic -std=c++11 -xc++ t.c
template 
int foo () { return 1; }

struct B {
unsigned c: foo;
};
t.c:5:17: error: width of bit-field ‘c’ has non-integral type ‘’
 unsigned c: foo;
 ^~~
t.c:5:17: internal compiler error: unexpected expression ‘foo’ of kind overload
0xaab7c1 cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3815
0xaabb75 cxx_eval_outermost_constant_expr
/src/gcc/trunk/gcc/cp/constexpr.c:3870
0xaac23b cxx_constant_value(tree_node*, tree_node*)
/src/gcc/trunk/gcc/cp/constexpr.c:3957
0x8c76c5 check_bitfield_decl
/src/gcc/trunk/gcc/cp/class.c:3439
0x8c9c3d check_field_decls
/src/gcc/trunk/gcc/cp/class.c:3818
0x8d55c8 check_bases_and_members
/src/gcc/trunk/gcc/cp/class.c:5738
0x8db8d8 finish_struct_1(tree_node*)
/src/gcc/trunk/gcc/cp/class.c:6887
0x8ddb0e finish_struct(tree_node*, tree_node*)
/src/gcc/trunk/gcc/cp/class.c:7201
0x943814 cp_parser_class_specifier_1
/src/gcc/trunk/gcc/cp/parser.c:21290
0x9444f9 cp_parser_class_specifier
/src/gcc/trunk/gcc/cp/parser.c:21518
0x938d3e cp_parser_type_specifier
/src/gcc/trunk/gcc/cp/parser.c:15817
0x933904 cp_parser_decl_specifier_seq
/src/gcc/trunk/gcc/cp/parser.c:12738
0x932e73 cp_parser_simple_declaration
/src/gcc/trunk/gcc/cp/parser.c:12281
0x932dfb cp_parser_block_declaration
/src/gcc/trunk/gcc/cp/parser.c:12228
0x932b6e cp_parser_declaration
/src/gcc/trunk/gcc/cp/parser.c:12125
0x9326a2 cp_parser_declaration_seq_opt
/src/gcc/trunk/gcc/cp/parser.c:12004
0x921e73 cp_parser_translation_unit
/src/gcc/trunk/gcc/cp/parser.c:4321
0x971d71 c_parse_file()
/src/gcc/trunk/gcc/cp/parser.c:37357
0xb2f3dd c_common_parse_file()
/src/gcc/trunk/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/69612] Optimizer does not consider overflow

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Roar Lauritzsen from comment #2)
> Thanks a lot for the quick analysis. Now that I know what it is I can fix my
> program, and the -fsanitize=undefined will come in handy for localizing
> problem areas. For future googlers, I am planning to fix my program along
> these lines:

Better use https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html

Re: [Patch, fortran, pr67451, v1] [5/6 Regression] ICE with sourced allocation from coarray

[Paul Richard Thomas]

Hi Andre,

This looks to be OK for trunk.

I'll move to the 5-branch patch right away.

Thanks

Paul

On 29 January 2016 at 19:17, Andre Vehreschild  wrote:
> Hi all,
>
> attached is a patch to fix a regression in current gfortran when a
> coarray is used in the source=-expression of an allocate(). The ICE was
> caused by the class information, i.e., _vptr and so on, not at the
> expected place. The patch fixes this.
>
> The patch also fixes pr69418, which I will flag as a duplicate in a
> second.
>
> Bootstrapped and regtested ok on x86_64-linux-gnu/F23.
>
> Ok for trunk?
>
> Backport to gcc-5 is pending, albeit more difficult, because the
> allocate() implementation on 5 is not as advanced the one in 6.
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

Re: [PATCH] c/69540 - update documentation on -l

[Sandra Loosemore]

On 01/30/2016 10:33 AM, Arkadiusz Drabczyk wrote:

* doc/invoke.texi: update documentation WRT .so libraries in -l
---
  gcc/ChangeLog   | 4 
  gcc/doc/invoke.texi | 8 +---
  2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1d60690..0a6acdb 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2016-01-30  Arkadiusz Drabczyk  
+
+   * doc/invoke.texi: update documentation WRT .so libraries in -l
+
  2016-01-29  Martin Jambor  

* hsa-gen.c (get_memory_order_name): Mask with MEMMODEL_BASE_MASK.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ba0b4b2..8b1b329 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10440,9 +10440,11 @@ whose members are object files.  The linker handles an 
archive file by
  scanning through it for members which define symbols that have so far
  been referenced but not defined.  But if the file that is found is an
  ordinary object file, it is linked in the usual fashion.  The only
-difference between using an @option{-l} option and specifying a file name
-is that @option{-l} surrounds @var{library} with @samp{lib} and @samp{.a}
-and searches several directories.
+difference between using an @option{-l} option and specifying a file
+name is that @option{-l} surrounds @var{library} with @samp{lib} and
+@samp{.so} on systems with shared libraries support or with @samp{.a} if
+@var{library} with @samp{.so} is not found and on all other systems and
+searches several directories.

  @item -lobjc
  @opindex lobjc



I see that the documentation of -l does need to be updated to mention 
.so files, but I think your patch doesn't go far enough.  It's already 
confusing because that sentence says "The only difference is...", and 
then mentions *two* things it does differently, and you're adding even 
more things.


Instead, I suggest dropping this confusing sentence entirely and putting 
the new information a couple paragraphs higher up:



The linker searches a standard list of directories for the library,
which is actually a file named @file{lib@var{library}.a}. The linker
then uses this file as if it had been specified precisely by name.


How about just changing that to read

...a file named @file{lib@var{library}.so}; or, if shared libraries are 
not supported, are disabled via @option{-static}, or no @samp{.so} file 
is found, @file{lib@var{library}.a}.


??

-Sandra

[Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Janus Weil]

Hi all,

here is a diagnostics patch, which makes sure that the responsible
flag is printed in several warning messages (for which this was still
missing).

The  only case that I'm not completely sure about is the hunk in
intrinsic.c. In particular I was not able to trigger this warning and
found no occurrence of it in the testsuite. Could someone check if the
flag that I'm using there is correct, please?

As a small extra the patch also mentions the -Wpedantic flag in the
gfortran documentation.

It regtests cleanly on x86_64-linux-gnu. Ok for trunk?

Cheers,
Janus


2016-02-01  Janus Weil  

PR fortran/69495
* invoke.texi: Mention -Wpedantic as an alias of -pedantic.
* check.c (gfc_check_transfer): Mention responsible flag in warning
message.
* frontend-passes.c (do_warn_function_elimination): Ditto.
* intrinsic.c (gfc_check_intrinsic_standard): Ditto.
* resolve.c (resolve_elemental_actual): Ditto.
(resolve_operator): Ditto.
(warn_unused_fortran_label): Ditto.
* trans-common.c (translate_common): Ditto.


2016-02-01  Janus Weil  

PR fortran/69495
* gfortran.dg/elemental_optional_args_6.f90: Use -Wpedantic flag.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (Revision 233091)
+++ gcc/fortran/check.c (Arbeitskopie)
@@ -5180,9 +5180,9 @@ gfc_check_transfer (gfc_expr *source, gfc_expr *mo
 return true;
 
   if (source_size < result_size)
-gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result: "
-"source size %ld < result size %ld", >where,
-(long) source_size, (long) result_size);
+gfc_warning (OPT_Wsurprising, "Intrinsic TRANSFER at %L has partly "
+"undefined result: source size %ld < result size %ld",
+>where, (long) source_size, (long) result_size);
 
   return true;
 }
Index: gcc/fortran/frontend-passes.c
===
--- gcc/fortran/frontend-passes.c   (Revision 233091)
+++ gcc/fortran/frontend-passes.c   (Arbeitskopie)
@@ -715,11 +715,11 @@ do_warn_function_elimination (gfc_expr *e)
   if (e->expr_type != EXPR_FUNCTION)
 return;
   if (e->value.function.esym)
-gfc_warning (0, "Removing call to function %qs at %L",
-e->value.function.esym->name, &(e->where));
+gfc_warning (OPT_Wfunction_elimination, "Removing call to function %qs "
+"at %L", e->value.function.esym->name, &(e->where));
   else if (e->value.function.isym)
-gfc_warning (0, "Removing call to function %qs at %L",
-e->value.function.isym->name, &(e->where));
+gfc_warning (OPT_Wfunction_elimination, "Removing call to function %qs "
+"at %L", e->value.function.isym->name, &(e->where));
 }
 /* Callback function for the code walker for doing common function
elimination.  This builds up the list of functions in the expression
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c (Revision 233091)
+++ gcc/fortran/intrinsic.c (Arbeitskopie)
@@ -4369,7 +4369,7 @@ gfc_check_intrinsic_standard (const gfc_intrinsic_
 {
   /* Do only print a warning if not a GNU extension.  */
   if (!silent && isym->standard != GFC_STD_GNU)
-   gfc_warning (0, "Intrinsic %qs (is %s) is used at %L",
+   gfc_warning (OPT_Wintrinsics_std, "Intrinsic %qs (is %s) is used at %L",
 isym->name, _(symstd_msg), );
 
   return true;
Index: gcc/fortran/invoke.texi
===
--- gcc/fortran/invoke.texi (Revision 233091)
+++ gcc/fortran/invoke.texi (Arbeitskopie)
@@ -709,8 +709,10 @@ Check the code for syntax errors, but do not actua
 will generate module files for each module present in the code, but no
 other output file.
 
-@item -pedantic
+@item -Wpedantic
+@itemx -pedantic
 @opindex @code{pedantic}
+@opindex @code{Wpedantic}
 Issue warnings for uses of extensions to Fortran 95.
 @option{-pedantic} also applies to C-language constructs where they
 occur in GNU Fortran source files, such as use of @samp{\e} in a
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (Revision 233091)
+++ gcc/fortran/resolve.c   (Arbeitskopie)
@@ -2127,9 +2127,9 @@ resolve_elemental_actual (gfc_expr *expr, gfc_code
  && (set_by_optional || arg->expr->rank != rank)
  && !(isym && isym->id == GFC_ISYM_CONVERSION))
{
- gfc_warning (0, "%qs at %L is an array and OPTIONAL; IF IT IS "
-  "MISSING, it cannot be the actual argument of an "
-  "ELEMENTAL procedure unless there is a non-optional "
+ gfc_warning (OPT_Wpedantic, "%qs at %L is an array and OPTIONAL; "
+

[Bug c/69612] Optimizer does not consider overflow

[roarl at pvv dot org]

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

--- Comment #2 from Roar Lauritzsen  ---
Thanks a lot for the quick analysis. Now that I know what it is I can fix my
program, and the -fsanitize=undefined will come in handy for localizing problem
areas. For future googlers, I am planning to fix my program along these lines:

unsigned test2(unsigned a) {
if ((int)a < 0)
return 1;
a++; // 0x7FFF + 1 is not undefined anymore
if ((int)a < 0)
return 2;
return a;
}

This code executes the way I want also with -O2, and there are no errors from
-fsanitize=undefined. Personally, I find it somewhat incongruent that integer
overflow is undefined, while integer casting is not, and I also find it very
disturbing that optimized and non-optimized code may behave differently.

Re: [PATCH] [graphite] document that isl-0.16 is supported

[Mike Stump]

On Feb 2, 2016, at 2:23 AM, Sebastian Huber 
 wrote:
> It would be good to have a recommended version as well (similar for cloog, 
> gmp, mpc and mpfr). If you present me three versions which one should I 
> choose as a naive user?

The latest release, or the one on your system.  This is so basic that we expect 
you to already know this.

> Are the versions in the contrib/download_prerequisites script the recommended 
> ones?

Yes, they are.

[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[meissner at linux dot vnet.ibm.com]

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

--- Comment #3 from Michael Meissner  ---
On Mon, Feb 01, 2016 at 11:35:35PM +, joseph at codesourcery dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69611
> 
> --- Comment #1 from joseph at codesourcery dot com  dot com> ---
> If __NO_FPRS__ is undefined, that means you are compiling for classic hard 
> float.  Which means that the soft-fp code is not needed - if you need to 
> keep it in libgcc_s.so for binary compatibility, using t-hardfp for 
> hard-float multilibs, as on powerpc*-*-linux*, would be better.

The issue is there are references to sfp-exceptions.o functions in the PowerPC
FreeBSD case, and sfp-exceptions.o is not built.  I tend to think using:

#ifdef __FLOAT128__

is cleaner at this point of time (stage4) than trying to make sure all of the
different PowerPC systems build correctly by adding sfp-exceptions.c to the
build list.

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[tom at compton dot nu]

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

--- Comment #14 from Tom Hughes  ---
Yes upstream took my fix to avoid the equality
(https://github.com/mapnik/node-mapnik/pull/589) but have also now noticed that
most of the FP can be one away with completely.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[spathiwa at gmail dot com]

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

--- Comment #7 from Craig Smith  ---
(In reply to Orion Poplawski from comment #6)
> (In reply to Craig Smith from comment #5)
> > For example, on RHEL 7, liblzma.so.5 is linked with -Ofast, which also
> > triggers crtfastmath.o to be used, corrupting the mxcsr register at library
> > load time.
> > (The bug might be specific to RedHat, because -Ofast is added in the rpm
> > spec.)
> 
> I don't see any evidence of liblzma.so.5 being linked with -Ofast on RHEL7,
> can you point to that?

The xz.spec file from the xz-5.1.2-0.alpha.1 source RPM includes the following:

%build
export CONFIGURE_TOP=`pwd`
mkdir objs
pushd objs
CFLAGS="%{optflags} -Ofast -funroll-loops" \
%configure2_5x
%make
popd

Re: [PATCH] c/69540 - update documentation on -l

[Arkadiusz Drabczyk]

On 2016-02-02, Sandra Loosemore  wrote:
> I see that the documentation of -l does need to be updated to mention 
> .so files, but I think your patch doesn't go far enough.  It's already 
> confusing because that sentence says "The only difference is...", and 
> then mentions *two* things it does differently, and you're adding even 
> more things.
>
> Instead, I suggest dropping this confusing sentence entirely and putting 
> the new information a couple paragraphs higher up:
>
>> The linker searches a standard list of directories for the library,
>> which is actually a file named @file{lib@var{library}.a}. The linker
>> then uses this file as if it had been specified precisely by name.
>
> How about just changing that to read
>
> ...a file named @file{lib@var{library}.so}; or, if shared libraries are 
> not supported, are disabled via @option{-static}, or no @samp{.so} file 
> is found, @file{lib@var{library}.a}.

Nice, indeed, more readable than what I came up with plus info on
-static added.  Looks good to me.

-- 
Arkadiusz Drabczyk 

[Bug c++/69635] 4x increase of build time [4.9 -> 6.0]

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to h2+bugs from comment #3)
> Thank you for the quick replies!
> 
> > Did you build gcc6 with --enable-checking=release ?
> 
> I am using the pre-built FreeBSD packages, I have checked, and it seems it
> is not the case. That likely explains it... I will double-check with the
> package maintainer.
> 
> > You can speed up the build time by using -flto=.
> 
> Ah, that's very interesting! I hadn't seen -flto with a number yet. Is there
> more documentation on it? 

Sure, in the compiler manual.

> Is this the "WHOPR" mode described here:
> https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html ?
> I had previously thought flto was only useful when linking multiple
> translation units... Does it have an effect on the produced binary?

For a single translation unit generally no. It just runs some 
optimizations and the code generation in parallel, hence the speedup.

[Bug rtl-optimization/67609] [5 Regression] Generates wrong code for SSE2 _mm_load_pd

[ubizjak at gmail dot com]

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

--- Comment #44 from Uroš Bizjak  ---
(In reply to rsand...@gcc.gnu.org from comment #43)
> FWIW, the proposed patch for PR69577 fixes this testcase
> with the aarch64_cannot_change_mode_class change reverted.
> The code quality looks slightly better too.

The same is true with x86_64. Following revert causes no testsuite regressions:

--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 233079)
+++ config/i386/i386.c  (working copy)
@@ -43283,25 +43283,12 @@ ix86_cannot_change_mode_class (machine_mode from,

   if (MAYBE_SSE_CLASS_P (regclass) || MAYBE_MMX_CLASS_P (regclass))
 {
-  int from_size = GET_MODE_SIZE (from);
-  int to_size = GET_MODE_SIZE (to);
-
   /* Vector registers do not support QI or HImode loads.  If we don't
 disallow a change to these modes, reload will assume it's ok to
 drop the subreg from (subreg:SI (reg:HI 100) 0).  This affects
 the vec_dupv4hi pattern.  */
-  if (from_size < 4)
+  if (GET_MODE_SIZE (from) < 4)
return true;
-
-  /* Further, we cannot allow word_mode subregs of full vector modes.
- Otherwise the middle-end will assume it's ok to store to
- (subreg:DI (reg:TI 100) 0) in order to modify only the low 64 bits
- of the 128-bit register.  However, after reload the subreg will
- be dropped leaving a plain DImode store.  This is indistinguishable
- from a "normal" DImode move, and so we're justified to use movsd,
- which modifies the entire 128-bit register.  */
-  if (to_size == UNITS_PER_WORD && from_size > UNITS_PER_WORD)
-   return true;
 }

   return false;
--cut here--

Re: Turnoff prefetching for -march=znver1

[Uros Bizjak]

On Tue, Feb 2, 2016 at 9:28 PM, Stepanyan, Victoria
 wrote:
> Hi Maintainers,
>
> This patch disables prefetching for -march=znver1 which is turned on by 
> default.
>
> gcc/ChangeLog:
>
> 2016-02-02 Victoria Stepanyan 
>
> * gcc/config/i386/x86-tune.def: Disable default prefetching for 
> -march=znver1
>
> Ok for trunk?

OK.

Thanks,
Uros.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[orion at cora dot nwra.com]

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

--- Comment #6 from Orion Poplawski  ---
(In reply to Craig Smith from comment #5)
> For example, on RHEL 7, liblzma.so.5 is linked with -Ofast, which also
> triggers crtfastmath.o to be used, corrupting the mxcsr register at library
> load time.
> (The bug might be specific to RedHat, because -Ofast is added in the rpm
> spec.)

I don't see any evidence of liblzma.so.5 being linked with -Ofast on RHEL7, can
you point to that?

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[orion at cora dot nwra.com]

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

--- Comment #8 from Orion Poplawski  ---
That version does not exist in RHEL7.  Looks like it was a Mandriva thing:
https://www.rpmfind.net/linux/RPM/mandriva/devel/cooker/x86_64/media/main/release/xz-5.1.2-0.alpha.1.x86_64.html

[Bug c++/69635] 4x increase of build time [4.9 -> 6.0]

[h2+bugs at fsfe dot org]

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

--- Comment #3 from h2+bugs at fsfe dot org ---
Thank you for the quick replies!

> Did you build gcc6 with --enable-checking=release ?

I am using the pre-built FreeBSD packages, I have checked, and it seems it is
not the case. That likely explains it... I will double-check with the package
maintainer.

> You can speed up the build time by using -flto=.

Ah, that's very interesting! I hadn't seen -flto with a number yet. Is there
more documentation on it? 
Is this the "WHOPR" mode described here:
https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html ?
I had previously thought flto was only useful when linking multiple translation
units... Does it have an effect on the produced binary?

Re: RFA: Add GCC Runtime Library Exception to include/plugin-api.h

[H.J. Lu]

On Tue, Feb 2, 2016 at 1:35 PM, Cary Coutant  wrote:
>> include/plugin-api.h defines an ABI between linker and compiler,
>> which can be used to implement linker plug-in by any compilers.
>> I'd like to add GCC Runtime Library Exception to include/plugin-api.h
>> so that the linker plug-in can have non-GPL licenses.
>
> This is OK with me.
>
> -cary

Here is a patch.  OK for trunk?

Thanks.

-- 
H.J.
From 3f8f62505774116d5de233ca36f60e3f8a840516 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Tue, 2 Feb 2016 14:02:03 -0800
Subject: [PATCH] Add GCC Runtime Library Exception to plugin-api.h

	* COPYING.RUNTIME: New file.
	* plugin-api.h: Add GCC Runtime Library Exception.
---
 include/COPYING.RUNTIME | 73 +
 include/plugin-api.h| 11 +++-
 2 files changed, 83 insertions(+), 1 deletion(-)
 create mode 100644 include/COPYING.RUNTIME

diff --git a/include/COPYING.RUNTIME b/include/COPYING.RUNTIME
new file mode 100644
index 000..e1b3c69
--- /dev/null
+++ b/include/COPYING.RUNTIME
@@ -0,0 +1,73 @@
+GCC RUNTIME LIBRARY EXCEPTION
+
+Version 3.1, 31 March 2009
+
+Copyright (C) 2009 Free Software Foundation, Inc. 
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+This GCC Runtime Library Exception ("Exception") is an additional
+permission under section 7 of the GNU General Public License, version
+3 ("GPLv3"). It applies to a given file (the "Runtime Library") that
+bears a notice placed by the copyright holder of the file stating that
+the file is governed by GPLv3 along with this Exception.
+
+When you use GCC to compile a program, GCC may combine portions of
+certain GCC header files and runtime libraries with the compiled
+program. The purpose of this Exception is to allow compilation of
+non-GPL (including proprietary) programs to use, in this way, the
+header files and runtime libraries covered by this Exception.
+
+0. Definitions.
+
+A file is an "Independent Module" if it either requires the Runtime
+Library for execution after a Compilation Process, or makes use of an
+interface provided by the Runtime Library, but is not otherwise based
+on the Runtime Library.
+
+"GCC" means a version of the GNU Compiler Collection, with or without
+modifications, governed by version 3 (or a specified later version) of
+the GNU General Public License (GPL) with the option of using any
+subsequent versions published by the FSF.
+
+"GPL-compatible Software" is software whose conditions of propagation,
+modification and use would permit combination with GCC in accord with
+the license of GCC.
+
+"Target Code" refers to output from any compiler for a real or virtual
+target processor architecture, in executable form or suitable for
+input to an assembler, loader, linker and/or execution
+phase. Notwithstanding that, Target Code does not include data in any
+format that is used as a compiler intermediate representation, or used
+for producing a compiler intermediate representation.
+
+The "Compilation Process" transforms code entirely represented in
+non-intermediate languages designed for human-written code, and/or in
+Java Virtual Machine byte code, into Target Code. Thus, for example,
+use of source code generators and preprocessors need not be considered
+part of the Compilation Process, since the Compilation Process can be
+understood as starting with the output of the generators or
+preprocessors.
+
+A Compilation Process is "Eligible" if it is done using GCC, alone or
+with other GPL-compatible software, or if it is done without using any
+work based on GCC. For example, using non-GPL-compatible Software to
+optimize any GCC intermediate representations would not qualify as an
+Eligible Compilation Process.
+
+1. Grant of Additional Permission.
+
+You have permission to propagate a work of Target Code formed by
+combining the Runtime Library with Independent Modules, even if such
+propagation would otherwise violate the terms of GPLv3, provided that
+all Target Code was generated by Eligible Compilation Processes. You
+may then convey such a combination under terms of your choice,
+consistent with the licensing of the Independent Modules.
+
+2. No Weakening of GCC Copyleft.
+
+The availability of this Exception does not imply any general
+presumption that third-party software is unaffected by the copyleft
+requirements of the license of GCC.
+
diff --git a/include/plugin-api.h b/include/plugin-api.h
index d7f9ee3..46686be 100644
--- a/include/plugin-api.h
+++ b/include/plugin-api.h
@@ -18,7 +18,16 @@
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
-   MA 02110-1301, USA.  */
+   MA 02110-1301, USA.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions 

[PATCH] Add GCC Runtime Library Exception to include/plugin-api.h

[H.J. Lu]

On Tue, Feb 2, 2016 at 1:35 PM, Cary Coutant  wrote:
>> include/plugin-api.h defines an ABI between linker and compiler,
>> which can be used to implement linker plug-in by any compilers.
>> I'd like to add GCC Runtime Library Exception to include/plugin-api.h
>> so that the linker plug-in can have non-GPL licenses.
>
> This is OK with me.
>
> -cary

Here is a patch.  OK for trunk?

Thanks.

-- 
H.J.
From 3f8f62505774116d5de233ca36f60e3f8a840516 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Tue, 2 Feb 2016 14:02:03 -0800
Subject: [PATCH] Add GCC Runtime Library Exception to plugin-api.h

	* COPYING.RUNTIME: New file.
	* plugin-api.h: Add GCC Runtime Library Exception.
---
 include/COPYING.RUNTIME | 73 +
 include/plugin-api.h| 11 +++-
 2 files changed, 83 insertions(+), 1 deletion(-)
 create mode 100644 include/COPYING.RUNTIME

diff --git a/include/COPYING.RUNTIME b/include/COPYING.RUNTIME
new file mode 100644
index 000..e1b3c69
--- /dev/null
+++ b/include/COPYING.RUNTIME
@@ -0,0 +1,73 @@
+GCC RUNTIME LIBRARY EXCEPTION
+
+Version 3.1, 31 March 2009
+
+Copyright (C) 2009 Free Software Foundation, Inc. 
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+This GCC Runtime Library Exception ("Exception") is an additional
+permission under section 7 of the GNU General Public License, version
+3 ("GPLv3"). It applies to a given file (the "Runtime Library") that
+bears a notice placed by the copyright holder of the file stating that
+the file is governed by GPLv3 along with this Exception.
+
+When you use GCC to compile a program, GCC may combine portions of
+certain GCC header files and runtime libraries with the compiled
+program. The purpose of this Exception is to allow compilation of
+non-GPL (including proprietary) programs to use, in this way, the
+header files and runtime libraries covered by this Exception.
+
+0. Definitions.
+
+A file is an "Independent Module" if it either requires the Runtime
+Library for execution after a Compilation Process, or makes use of an
+interface provided by the Runtime Library, but is not otherwise based
+on the Runtime Library.
+
+"GCC" means a version of the GNU Compiler Collection, with or without
+modifications, governed by version 3 (or a specified later version) of
+the GNU General Public License (GPL) with the option of using any
+subsequent versions published by the FSF.
+
+"GPL-compatible Software" is software whose conditions of propagation,
+modification and use would permit combination with GCC in accord with
+the license of GCC.
+
+"Target Code" refers to output from any compiler for a real or virtual
+target processor architecture, in executable form or suitable for
+input to an assembler, loader, linker and/or execution
+phase. Notwithstanding that, Target Code does not include data in any
+format that is used as a compiler intermediate representation, or used
+for producing a compiler intermediate representation.
+
+The "Compilation Process" transforms code entirely represented in
+non-intermediate languages designed for human-written code, and/or in
+Java Virtual Machine byte code, into Target Code. Thus, for example,
+use of source code generators and preprocessors need not be considered
+part of the Compilation Process, since the Compilation Process can be
+understood as starting with the output of the generators or
+preprocessors.
+
+A Compilation Process is "Eligible" if it is done using GCC, alone or
+with other GPL-compatible software, or if it is done without using any
+work based on GCC. For example, using non-GPL-compatible Software to
+optimize any GCC intermediate representations would not qualify as an
+Eligible Compilation Process.
+
+1. Grant of Additional Permission.
+
+You have permission to propagate a work of Target Code formed by
+combining the Runtime Library with Independent Modules, even if such
+propagation would otherwise violate the terms of GPLv3, provided that
+all Target Code was generated by Eligible Compilation Processes. You
+may then convey such a combination under terms of your choice,
+consistent with the licensing of the Independent Modules.
+
+2. No Weakening of GCC Copyleft.
+
+The availability of this Exception does not imply any general
+presumption that third-party software is unaffected by the copyleft
+requirements of the license of GCC.
+
diff --git a/include/plugin-api.h b/include/plugin-api.h
index d7f9ee3..46686be 100644
--- a/include/plugin-api.h
+++ b/include/plugin-api.h
@@ -18,7 +18,16 @@
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
-   MA 02110-1301, USA.  */
+   MA 02110-1301, USA.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions 

[Bug c++/69640] ~SomeClass() = default; incorrectly considered a "user-declared destructor"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
You're not even using GCC, you're using CLang, so you should be at
https://llvm.org/bugs/

In any case, that is a user-declared destructor, so Clang is correct.

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[ppalka at gcc dot gnu.org]

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

--- Comment #12 from Patrick Palka  ---
(In reply to Patrick Palka from comment #11)
> More reduced test case, that does not depend on -ipa-icf:
> 
> struct R
> {
>   R (const R&) { }
> };
> 
> __attribute__ ((noreturn)) R f ();
> 
> R
> c ()
> {
>   f ();
> }
> 
> Untested fix:
> 
> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index ce1e712..e07cd04 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -4830,7 +4830,8 @@ gimplify_modify_expr (tree *expr_p, gimple_seq *pre_p,
> gimple_seq *post_p,
> }
> }
>notice_special_calls (call_stmt);
> -  if (!gimple_call_noreturn_p (call_stmt))
> +  if (!gimple_call_noreturn_p (call_stmt)
> + || gimple_call_return_slot_opt_p (call_stmt))
> gimple_call_set_lhs (call_stmt, *to_p);
>assign = call_stmt;
>  }

Actually in light of #c2 this might be a separate but related issue.

[Bug c++/69640] New: ~SomeClass() = default; incorrectly considered a "user-declared destructor"

[j...@yates-sheets.org]

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

Bug ID: 69640
   Summary: ~SomeClass() = default; incorrectly considered a
"user-declared destructor"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j...@yates-sheets.org
  Target Milestone: ---

warning: definition of implicit copy constructor for 'IntRange' is deprecated
because it has a user-declared destructor [-Wdeprecated]
~IntRange() =default;
^
...: note: implicit copy constructor for 'IntRange' first required here
return IntRange(aTargetSizes);

[Bug target/69639] [6 Regression] FAIL: gcc.c-torture/compile/limits-exprparen.c

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
(gdb) r
Starting program: /test/gnu/gcc/objdir/stage1-gcc/cc1 -fpreprocessed
limits-exprparen.i -quiet -dumpbase limits-exprparen.c -auxbase-strip
limits-exprparen.o -O0 -w -version -fdiagnostics-color=never
-fno-diagnostics-show-caret -o limits-exprparen.s
warning: Private mapping of shared library text was not specified
by the executable; setting a breakpoint in a shared library which
is not privately mapped will not work.  See the HP-UX 11i v3 chatr
manpage for methods to privately map shared library text.
GNU C11 (GCC) version 6.0.0 20160201 (experimental) [trunk revision 233038]
(hppa2.0w-hp-hpux11.11)
compiled by GNU C version 5.2.1 20150716 [gcc-5-branch revision
225904], GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.3, isl version
none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (GCC) version 6.0.0 20160201 (experimental) [trunk revision 233038]
(hppa2.0w-hp-hpux11.11)
compiled by GNU C version 5.2.1 20150716 [gcc-5-branch revision
225904], GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.3, isl version
none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: f2dd5e0bce1bf74507a5dd14a956b7c9

Pid 7906 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.

Program received signal SIGSEGV, Segmentation fault.
0x00185078 in _ZL19c_parser_peek_tokenP8c_parser (parser=0x0)
at ../../gcc/gcc/c/c-parser.c:452
452 {
(gdb) bt
Python Exception  Failed to load
/home/gnu/lib/python2.7/lib-dynload/itertools.sl:
#0  0x00185078 in _ZL19c_parser_peek_tokenP8c_parser (parser=0x0)
at ../../gcc/gcc/c/c-parser.c:452
#1  0x0019a734 in _ZL24c_parser_cast_expressionP8c_parserP6c_expr (
parser=0x7aead000, after=0x0) at ../../gcc/gcc/c/c-parser.c:6653
#2  0x0019950c in _ZL26c_parser_binary_expressionP8c_parserP6c_exprP9tree_node
(parser=0x7aead000, after=0x0, omp_atomic_lhs=0x0)
at ../../gcc/gcc/c/c-parser.c:6508
#3  0x00198980 in
_ZL31c_parser_conditional_expressionP8c_parserP6c_exprP9tree_node
(parser=0x7aead000, after=0x0, omp_atomic_lhs=0x0)
at ../../gcc/gcc/c/c-parser.c:6279
#4  0x00198460 in _ZL23c_parser_expr_no_commasP8c_parserP6c_exprP9tree_node (
parser=0x7aead000, after=0x0, omp_atomic_lhs=0x0)
at ../../gcc/gcc/c/c-parser.c:6196
#5  0x001a33a0 in _ZL19c_parser_expressionP8c_parser (parser=0x7aead000)
at ../../gcc/gcc/c/c-parser.c:8381
#6  0x0019e7c8 in _ZL27c_parser_postfix_expressionP8c_parser (
parser=0x7aead000) at ../../gcc/gcc/c/c-parser.c:7522
#7  0x0019badc in _ZL25c_parser_unary_expressionP8c_parser (parser=0x7aead000)
at ../../gcc/gcc/c/c-parser.c:6870
#8  0x0019aab0 in _ZL24c_parser_cast_expressionP8c_parserP6c_expr (
parser=0x7aead000, after=0x0) at ../../gcc/gcc/c/c-parser.c:6699
#9  0x0019950c in _ZL26c_parser_binary_expressionP8c_parserP6c_exprP9tree_node
(parser=0x7aead000, after=0x0, omp_atomic_lhs=0x0)
---Type  to continue, or q  to quit---
at ../../gcc/gcc/c/c-parser.c:6508
#10 0x00198980 in
_ZL31c_parser_conditional_expressionP8c_parserP6c_exprP9tree_node
(parser=0x7aead000, after=0x0, omp_atomic_lhs=0x0)
at ../../gcc/gcc/c/c-parser.c:6279
#11 0x00198460 in _ZL23c_parser_expr_no_commasP8c_parserP6c_exprP9tree_node (
parser=0x7aead000, after=0x0, omp_atomic_lhs=0x0)
at ../../gcc/gcc/c/c-parser.c:6196
#12 0x001a33a0 in _ZL19c_parser_expressionP8c_parser (parser=0x7aead000)
at ../../gcc/gcc/c/c-parser.c:8381
#13 0x0019e7c8 in _ZL27c_parser_postfix_expressionP8c_parser (
parser=0x7aead000) at ../../gcc/gcc/c/c-parser.c:7522
#14 0x0019badc in _ZL25c_parser_unary_expressionP8c_parser (parser=0x7aead000)
at ../../gcc/gcc/c/c-parser.c:6870
#15 0x0019aab0 in _ZL24c_parser_cast_expressionP8c_parserP6c_expr (
parser=0x7aead000, after=0x0) at ../../gcc/gcc/c/c-parser.c:6699
#16 0x0019950c in _ZL26c_parser_binary_expressionP8c_parserP6c_exprP9tree_node
(parser=0x7aead000, after=0x0, omp_atomic_lhs=0x0)
at ../../gcc/gcc/c/c-parser.c:6508
#17 0x00198980 in
_ZL31c_parser_conditional_expressionP8c_parserP6c_exprP9tree_node
(parser=0x7aead000, after=0x0, omp_atomic_lhs=0x0)
at ../../gcc/gcc/c/c-parser.c:6279
#18 0x00198460 in _ZL23c_parser_expr_no_commasP8c_parserP6c_exprP9tree_node (
parser=0x7aead000, after=0x0, omp_atomic_lhs=0x0)
[...]

We have similar backtrace with stage3 compuler.

(gdb) p *parser
$1 = {tokens = 0x7aead004, tokens_buf = {{type = CPP_OPEN_PAREN,
  id_kind = C_ID_NONE, keyword = RID_MAX, pragma_kind = PRAGMA_NONE,
  location = 151584, value = 0x0}, {type = CPP_OPEN_PAREN,
  id_kind = C_ID_NONE, keyword = RID_MAX, pragma_kind = PRAGMA_NONE,
  location = 151584, value = 0x0}, {type = CPP_EQ, id_kind = C_ID_ID,
  keyword = RID_STATIC, pragma_kind = PRAGMA_NONE, location = 0,
  value = 

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[bernds at gcc dot gnu.org]

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

--- Comment #13 from Bernd Schmidt  ---
Or, you know, operate on integers. Skip the / 255.0 step where it is
unnecessary.

[PATCH] vector-compare-4.c

[Segher Boessenkool]

This testcase fails on 32-bit powerpc-linux with

Excess errors:
/home/segher/src/gcc/gcc/testsuite/c-c++-common/vector-compare-4.c:31:1: 
warning: GCC vector returned by reference: non-standard ABI extension with no 
compatibility guarantee

Fix this as in vector-compare-2.c .

Tested on powerpc64-linux, -m32 and -m64; installing as obvious.


Segher


2016-02-02  Segher Boessenkool  

testsuite/
* c-c++-common/vector-compare-4.c: Prune "non-standard ABI extension"
warning.

---
 gcc/testsuite/c-c++-common/vector-compare-4.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/testsuite/c-c++-common/vector-compare-4.c 
b/gcc/testsuite/c-c++-common/vector-compare-4.c
index b44f474..b05decc 100644
--- a/gcc/testsuite/c-c++-common/vector-compare-4.c
+++ b/gcc/testsuite/c-c++-common/vector-compare-4.c
@@ -1,6 +1,8 @@
 /* PR c/68062 */
 /* { dg-do compile } */
 /* { dg-options "-Wsign-compare" } */
+/* Ignore warning on some powerpc configurations. */
+/* { dg-prune-output "non-standard ABI extension" } */
 
 typedef signed char __attribute__ ((vector_size (4))) v4qi;
 typedef unsigned char __attribute__ ((vector_size (4))) uv4qi;
-- 
1.9.3

[wwwdocs] Add common C++ issues to /gcc-6/porting_to.html

[Jonathan Wakely]

This documents the most likely problems for C++ programs using GCC 6.

Committed to CVS.

Index: htdocs/gcc-6/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.2
diff -u -r1.2 porting_to.html
--- htdocs/gcc-6/porting_to.html	27 Jan 2016 14:40:26 -	1.2
+++ htdocs/gcc-6/porting_to.html	2 Feb 2016 20:32:29 -
@@ -33,6 +33,132 @@
 
 C++ language issues
 
+Default standard is now GNU++14
+
+
+GCC defaults to -std=gnu++14 instead of -std=gnu++98.
+This brings several changes that users should be aware of.  The following
+paragraphs describe some of these changes and suggest how to deal with them.
+
+
+Some users might prefer to stay with gnu++98, in which case we suggest to
+use the -std=gnu++98 command-line option, perhaps by putting it
+in CXXFLAGS or similar variables in Makefiles.
+
+Narrowing conversions
+
+
+The C++11 standard does not allow "narrowing conversions" inside braced
+initialization lists, meaning conversions to a type with less precision or
+a smaller range, for example:
+
+
+int i = 127;
+char s[] = { i, 256 };
+
+
+
+In the above example the value 127 would fit in char but
+because it's not a constant it is still a narrowing conversion. If the value
+256 is larger than CHAR_MAX then that is also a narrowing
+conversion. Narrowing conversions can be avoided by using an explicit cast,
+e.g. (char)i.
+
+
+Invalid literal suffixes
+
+
+The C++11 "user-defined literals" feature allows custom suffixes to be added
+to literals, so that for example "Hello, world!"s creates a
+std::string object. This means that code relying on string
+concatenation of string literals and macros might fail to compile, for
+example using printf("%"PRIu64, uint64_value) is not valid in
+C++11, because PRIu64 is parsed as a literal suffix. To fix
+the code to compile in C++11 add whitespace between the string literal and the
+macro: printf("%" PRIu64, uint64_value).
+
+
+Cannot convert 'bool' to 'T*'
+
+
+The current C++ standard only allows integer literals to be used as null
+pointer constants, so other constants such as false and
+(1 - 1) cannot be used where a null pointer is desired. Code that
+fails to compile with this error should be changed to use nullptr,
+or 0, or NULL.
+
+
+Cannot convert 'std::ostream' to 'bool'
+
+
+Since C++11 iostream classes are no longer implicitly convertible to
+void* so it is no longer valid to do something like:
+
+
+  bool valid(std::ostream os) { return os; }
+
+
+
+Such code must be changed to convert the iostream object to bool
+explicitly:
+
+
+
+  bool valid(std::ostream os) { return (bool)os; }
+
+
+Header dependency changes
+
+
+The algorithm header has been changed to reduce the
+number of other headers it includes in C++11 mode or above.
+As such, C++ programs that used components defined in
+random, vector, or
+memory without explicitly including the right headers
+will no longer compile.
+
+
+Header cmath changes
+
+
+Some C libraries declare obsolete int isinf(double) or
+int isnan(double) functions in the math.h
+header. These functions conflict with standard C++ functions with the same
+name but a different return type (the C++ functions return bool).
+When the obsolete functions are declared by the C library the C++ library
+will use them and import them into namespace std
+instead of defining the correct signatures.
+
+
+Header math.h changes
+
+
+The C++ library now provides its own math.h header that
+wraps the C library header of the same name. The C++ header defines
+additional overloads of some functions and ensures that all standard
+functions are defined as real functions and not as macros.
+Code which assumes that sin, cos, pow,
+isfinite etc. are macros may no longer compile.
+
+
+Header stdlib.h changes
+
+
+The C++ library now provides its own stdlib.h header that
+wraps the C library header of the same name. The C++ header defines
+additional overloads of some functions and ensures that all standard
+functions are defined as real functions and not as macros.
+Code which assumes that abs, malloc etc.
+are macros may no longer compile.
+
+
+
+Programs which provide their own wrappers for stdlib.h
+or other standard headers are operating outside the standard and so are
+responsible for ensuring their headers work correctly with the headers in
+the C++ standard library.
+
+
 -Wmisleading-indentation
 
 A new warning -Wmisleading-indentation was added

Re: RFA: Add GCC Runtime Library Exception to include/plugin-api.h

[Cary Coutant]

> include/plugin-api.h defines an ABI between linker and compiler,
> which can be used to implement linker plug-in by any compilers.
> I'd like to add GCC Runtime Library Exception to include/plugin-api.h
> so that the linker plug-in can have non-GPL licenses.

This is OK with me.

-cary

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[spathiwa at gmail dot com]

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

Craig Smith  changed:

   What|Removed |Added

 CC||spathiwa at gmail dot com

--- Comment #5 from Craig Smith  ---
This issue is really, really bad, and has potential to start changing more and
more run-time behavior of downstream libraries and apps the longer this bug
persists.

For example, on RHEL 7, liblzma.so.5 is linked with -Ofast, which also triggers
crtfastmeth.o to be used, corrupting the mxcsr register at library load time.
(The bug might be specific to RedHat, because -Ofast is added in the rpm spec.)

For some reason, Open GL libraries (libglapi) depend on libselinux which
depends on liblzma.

So ANY open GL app on RHEL will now have its math/IEEE754 semantics broken.

That's terrible.

crtfastmath.o should NEVER be used when linking shared libraries, regardless of
options.

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #11 from Patrick Palka  ---
More reduced test case, that does not depend on -ipa-icf:

struct R
{
  R (const R&) { }
};

__attribute__ ((noreturn)) R f ();

R
c ()
{
  f ();
}

Untested fix:

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index ce1e712..e07cd04 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -4830,7 +4830,8 @@ gimplify_modify_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p,
}
}
   notice_special_calls (call_stmt);
-  if (!gimple_call_noreturn_p (call_stmt))
+  if (!gimple_call_noreturn_p (call_stmt)
+ || gimple_call_return_slot_opt_p (call_stmt))
gimple_call_set_lhs (call_stmt, *to_p);
   assign = call_stmt;
 }

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[luto at kernel dot org]

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

Andy Lutomirski  changed:

   What|Removed |Added

   Severity|enhancement |major

--- Comment #9 from Andy Lutomirski  ---
I'm changing this from an enhancement to a bug.  It's a poor design, no one
seems to think it's a good idea, and it's broken more than one thing in real
life.

Re: [Patch, MIPS] Fix PR target/68273, passing args in wrong regs

[Steve Ellcey]

On Sat, 2016-01-30 at 11:06 +, Richard Sandiford wrote:

> We need to be careful of examples like:
> 
>   struct __attribute__ ((aligned (8))) s { _Complex float x; };
>   void foo (struct s *ptr, struct s val) { *ptr = val; }
> 
> "x" gets SCmode, which has an alignment of 4.  And it's OK for TYPE_MODE
> to have a smaller alignment than the type -- it's just not allowed to
> have a larger alignment (and even that restriction only applies because
> this is a STRICT_ALIGNMENT target).  So the structure itself inherits
> this SCmode.
> 
> The patch therefore changes how we handle foo() for -mabi=32 -msoft-float.
> Before the patch "val" is passed in $6 and $7.  After the patch it's
> passed in $5 and $6.  clang behaves like the unpatched GCC.
> 
> If instead we use:
> 
>   struct __attribute__ ((aligned (8))) s { float x; float y; };
>   void foo (struct s *ptr, struct s val) { *ptr = val; }
> 
> then the structure has BLKmode and the alignment is honoured both before
> and after the patch.
> 
> There's no real ABI reason for handling the two cases differently.
> The fact that one gets BLKmode and the other doesn't is down
> to GCC internals.
> 
> We also have to be careful about the STRICT_ALIGNMENT thing.
> At the moment that's hard-coded to 1 for MIPS, but it's possible that
> it could become configurable in future, like it is for aarch64 and
> rs6000.  !STRICT_ALIGNMENT allows TYPE_MODE to have a larger
> alignment than the type, so underaligned structures would get modes
> when they didn't previously.  That would in turn change how they're
> passed as arguments.
> 
> Thanks,
> Richard

Richard,

Can you explain why the GCC internals cause us to get SCmode instead of
BLKmode for the example with _Complex?  I don't understand that.  It
seems wrong to me and I don't understand where it is coming from.

Steve Ellcey
sell...@imgtec.com

[Bug driver/69642] New: command-line spell check should know about "no-"

[segher at gcc dot gnu.org]

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

Bug ID: 69642
   Summary: command-line spell check should know about "no-"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

$ echo > nope.c
$ gcc -fno-semantic-interpolation nope.c
gcc: error: unrecognized command line option '-fno-semantic-interpolation'; did
you mean '-fsemantic-interposition'?

This confused me for a bit; it would be nice if it could suggest
"did you mean '-fno-semantic-interposition'?" instead.

[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
I think it's OK for stage 4 - the t-hardfp point is that you'd get a 
smaller, faster libgcc on FreeBSD that way, by not compiling soft-fp at 
all for non-float128 hard float.

gcc-5-20160202 is now available

[gccadmin]

Snapshot gcc-5-20160202 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160202/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 233093

You'll find:

 gcc-5-20160202.tar.bz2   Complete GCC

  MD5=c4f4b42ca3b4c0cdeb1b83934d32e182
  SHA1=4b895bb0b4471d01bd2e5659180ddc6677458c90

Diffs from 5-20160126 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug driver/69642] command-line spell check should know about "no-"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
An exact dup of bug 69453 (though the subject could be improved to talk about
the "no" part rather than saying negation :)).

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

[Bug driver/69453] unrecognized command line option suggestions should take negation into account

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

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

[Bug c++/69641] New: invalid int32 comparison

[vvsed at hotmail dot com]

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

Bug ID: 69641
   Summary: invalid int32 comparison
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vvsed at hotmail dot com
  Target Milestone: ---

The program prints 0 1 instead of 1 1.
Same behavior with gcc 4.8 and 5.1, with both -m64 and -m32.

/*
D:\Tools\MinGW64\bin\g++.exe -m64 -O2 -Wall -save-temps gcerr.cpp -ovx_class_gc

Compiler: http://tdm-gcc.tdragon.net/about

invalid int32 comparison
*/

#include 

int main(int argc, const char *argv[])
{
int i = 0x7F80;

fprintf(stdout, "%d \n", 0 > (int)(i + 0x0080));
fprintf(stdout, "%d \n", 0 > (int)0x8000);

fprintf(stdout, "press Enter");
getc(stdin);
return 0;
}

[Bug c++/69641] invalid int32 comparison

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
You're invoking undefined behavior (signed integer overflow).

[Bug target/69577] [5/6 Regression] wrong code with -fno-forward-propagate -mavx and 128bit arithmetics since r215450

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #10 from Richard Henderson  ---
This does look plausible as a replacement for the hacks
I added in cannot_change_mode_class.

Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.

[Joern Wolfgang Rennecke]

On 01/02/16 13:57, Claudiu Zissulescu wrote:

In this patch, we add support for the new FPU instructions available with
ARC V2 processors.  The new FPU instructions covers both single and
double precision IEEE formats. While the single precision is available
for both ARC EM and ARC HS processors, the double precision is only
available for ARC HS. ARC EM will make use of the double precision assist
instructions which are in fact FPX double instructions.  The double
floating point precision instructions are making use of the odd-even
register pairs to hold 64-bit datums, exactly like in the case of ldd/std
instructions.

Additional to the mods required by FPU instructions to be supported by
GCC, we forced all the 64 bit datum to use odd-even register pairs (HS
only), as we observed a better usage of the ldd/std, and less generated
move instructions.  A byproduct of this optimization, is a new ABI, which
places the 64-bit arguments into odd-even register pairs.  This behavior
can be selected using -mabi option.

Feedback is welcomed,


  VECTOR_MODES (INT, 16);   /* V16QI V8HI V4SI V2DI */
+
+/* FPU conditon flags. */

Typo

+   error ("FPU double precission options are available for ARC HS 
only.");


There should be no period at the end of the error message string.

+  if (TARGET_HS && (arc_fpu_build & FPX_DP))
+   error ("FPU double precission assist "

Typo.  And Ditto.


+  case EQ:
+  case NE:
+  case UNORDERED:
+  case UNLT:
+  case UNLE:
+  case UNGT:
+  case UNGE:
+   return CC_FPUmode;
+
+  case LT:
+  case LE:
+  case GT:
+  case GE:
+  case ORDERED:
+   return CC_FPUEmode;

cse and other code transformations are likely to do better if you use
just one mode for these.  It is also very odd to have comparisons and their
inverse use different modes.  Have you done any benchmarking for this?

@@ -1282,6 +1363,16 @@ arc_conditional_register_usage (void)
arc_hard_regno_mode_ok[60] = 1 << (int) S_MODE;
 }

+  /* ARCHS has 64-bit data-path which makes use of the even-odd paired
+ registers.  */
+  if (TARGET_HS)
+{
+  for (regno = 1; regno < 32; regno +=2)
+   {
+ arc_hard_regno_mode_ok[regno] = S_MODES;
+   }
+}
+

Does TARGET_HS with -mabi=default allow for passing DFmode / DImode 
arguments

in odd registers?  I fear you might run into reload trouble when trying to
access the values.

+arc_hard_regno_nregs (int regno,
...
+  if ((regno < FIRST_PSEUDO_REGISTER)
+  && (HARD_REGNO_MODE_OK (regno, mode)
+ || (mode == BLKmode)))
+return words;
+  return 0;

This prima facie contradicts HARD_REGNO_NREGS, which considers the
larger sizes of simd vector and dma config registers.
I see that there is no actual conflict as the vector registers are not
used for argument passing, but the comment in the function only states
what the function does - not quite correctly, as detailed before - and
not what it is for.

So, either the mxp support has to be removed before this patch goes in,
or arc_hard_regno_nregs has to handle simd registers properly, or the
comment at the top should state the limited applicability of this
function, and there should be an assert to check that the register
number passed is suitable - e.g.:
gcc_assert (regno < ARC_FIRST_SIMD_VR_REG)

+/* Given an CUMULATIVE_ARGS, this function returns an RTX if the

Typo: C is not a vowel.

+  if (!named && TARGET_HS)
+{
+  /* For unamed args don't try fill up the reg-holes.  */
+  reg_idx = cum->last_reg;
+  /* Only interested in the number of regs.  */

You should make up your mind what the priorities for stdarg are.
Traditionally, lots of gcc ports have supported broken code that lacks
declarations of variadic functions, and furthermore have placed
emphasis on simplicity of varargs/stdarg callee code, at the expense
of normal code.  Often for compatibility with a pre-existing
compiler, sometimes by just copying from existing ports without
stopping to consider the ramifications.
If you make argument passing different for stdarg declared functions,
the broken code that lacks declarations won't work any more.
Ignoring registers for argument passing is not helping the callers
code density.  So the only objective that might be furthered here
is stdarg callee simplicity.  But if you really want that, and ignore
compatibility with broken code, the logical thing to do is not to
pass any unnamed arguments in registers.

If stdarg caller's code size is considered important, and stdarg
callees mostly irrelevant (as mostly associated with I/O, and
linked in just once per function), this aligns well with supporting
broken code: it shouldn't matter if the argument is anonymous or
not, it's the same effort for the caller to pass it.

One further thing to consider when forging new ABIs is that
partial argument passing is there solely for the convenience of
stdarg callees, and/or the programmer who wrote that part of
the 

New Brazilian Portuguese PO file for 'cpplib' (version 6.1-b20160131)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Brazilian Portuguese team of translators.  The file is available at:

http://translationproject.org/latest/cpplib/pt_BR.po

(This file, 'cpplib-6.1-b20160131.pt_BR.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[spathiwa at gmail dot com]

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

--- Comment #10 from Craig Smith  ---
(In reply to Orion Poplawski from comment #8)
> That version does not exist in RHEL7.  Looks like it was a Mandriva thing:
> https://www.rpmfind.net/linux/RPM/mandriva/devel/cooker/x86_64/media/main/
> release/xz-5.1.2-0.alpha.1.x86_64.html

rpm -qi liblzma5 on my RHEL 7 system says that the source RPM is the one I
mentioned, with build host 'n2.mandriva.com'.  Not sure why this is that case,
if a build image got corrupted or someone manually installed an rpm form
Mandriva on this system without my knowledge.

In any case, the GCC bug is causing real issues, even if possibly not on RHEL
7.  I'll find another RHEL 7 system and check.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #8 from Bill Schmidt  ---
Martin, per the description of _atomic_load in the GCC manual, this appears to
be invalid code.  Do you disagree?  Of course we should probably die more
gracefully, but in both cases _atomic_load appears to be called in an invalid
manner.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Same question for Markus.  Sorry for conflating the two of you. :)

[Bug c++/69641] invalid int32 comparison

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
https://gcc.gnu.org/wiki/FAQ#signed_overflow

Re: Status of GCC 6 on x86_64 (Debian)

[Matthias Klose]

On 22.01.2016 08:27, Matthias Klose wrote:

On 22.01.2016 06:09, Martin Michlmayr wrote:

In terms of build failures, I reported 520 bugs to Debian.  Most of them
were new GCC errors or warnings (some packages use -Werror and many
-Werror=format-security).

Here are some of the most frequent errors see:


[...]
Martin tagged these issues; https://wiki.debian.org/GCC6 has links with these
bug searches.


Now added the issues with the gcc6-unknown tag, including packages with build 
failures in running the test suites, which might point out wrong-code issues.


see
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gcc-6-unknown;users=debian-...@lists.debian.org

[PATCH] s390: Add -fsplit-stack support

[Marcin Kościelnicki]

libgcc/ChangeLog:

* config.host: Use t-stack and t-stack-s390 for s390*-*-linux.
* config/s390/morestack.S: New file.
* config/s390/t-stack-s390: New file.
* generic-morestack.c (__splitstack_find): Add s390-specific code.

gcc/ChangeLog:

* common/config/s390/s390-common.c (s390_supports_split_stack):
New function.
(TARGET_SUPPORTS_SPLIT_STACK): New macro.
* config/s390/s390-protos.h: Add s390_expand_split_stack_prologue.
* config/s390/s390.c (struct machine_function): New field
split_stack_varargs_pointer.
(s390_register_info): Mark r12 as clobbered if it'll be used as temp
in s390_emit_prologue.
(s390_emit_prologue): Use r12 as temp if r1 is taken by split-stack
vararg pointer.
(morestack_ref): New global.
(SPLIT_STACK_AVAILABLE): New macro.
(s390_expand_split_stack_prologue): New function.
(s390_live_on_entry): New function.
(s390_va_start): Use split-stack vararg pointer if appropriate.
(s390_asm_file_end): Emit the split-stack note sections.
(TARGET_EXTRA_LIVE_ON_ENTRY): New macro.
* config/s390/s390.md (UNSPEC_STACK_CHECK): New unspec.
(UNSPECV_SPLIT_STACK_CALL): New unspec.
(UNSPECV_SPLIT_STACK_DATA): New unspec.
(split_stack_prologue): New expand.
(split_stack_space_check): New expand.
(split_stack_data): New insn.
(split_stack_call): New expand.
(split_stack_call_*): New insn.
(split_stack_cond_call): New expand.
(split_stack_cond_call_*): New insn.
---
Comment fixed, split_stack_marker gone, reorg gone.  Generated code seems sane,
but testsuite still running.

I will need to modify the gold patch to handle the "leaf function taking 
non-split
stack function address" issue - this will likely require messing with the target
independent plumbing, the hook for that doesn't seem to get enough params.

 gcc/ChangeLog|  30 ++
 gcc/common/config/s390/s390-common.c |  14 +
 gcc/config/s390/s390-protos.h|   1 +
 gcc/config/s390/s390.c   | 214 +++-
 gcc/config/s390/s390.md  | 138 
 libgcc/ChangeLog |   7 +
 libgcc/config.host   |   4 +-
 libgcc/config/s390/morestack.S   | 609 +++
 libgcc/config/s390/t-stack-s390  |   2 +
 libgcc/generic-morestack.c   |   4 +
 10 files changed, 1016 insertions(+), 7 deletions(-)
 create mode 100644 libgcc/config/s390/morestack.S
 create mode 100644 libgcc/config/s390/t-stack-s390

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 9a2cec8..568dff4 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,33 @@
+2016-02-02  Marcin Kościelnicki  
+
+   * common/config/s390/s390-common.c (s390_supports_split_stack):
+   New function.
+   (TARGET_SUPPORTS_SPLIT_STACK): New macro.
+   * config/s390/s390-protos.h: Add s390_expand_split_stack_prologue.
+   * config/s390/s390.c (struct machine_function): New field
+   split_stack_varargs_pointer.
+   (s390_register_info): Mark r12 as clobbered if it'll be used as temp
+   in s390_emit_prologue.
+   (s390_emit_prologue): Use r12 as temp if r1 is taken by split-stack
+   vararg pointer.
+   (morestack_ref): New global.
+   (SPLIT_STACK_AVAILABLE): New macro.
+   (s390_expand_split_stack_prologue): New function.
+   (s390_live_on_entry): New function.
+   (s390_va_start): Use split-stack vararg pointer if appropriate.
+   (s390_asm_file_end): Emit the split-stack note sections.
+   (TARGET_EXTRA_LIVE_ON_ENTRY): New macro.
+   * config/s390/s390.md (UNSPEC_STACK_CHECK): New unspec.
+   (UNSPECV_SPLIT_STACK_CALL): New unspec.
+   (UNSPECV_SPLIT_STACK_DATA): New unspec.
+   (split_stack_prologue): New expand.
+   (split_stack_space_check): New expand.
+   (split_stack_data): New insn.
+   (split_stack_call): New expand.
+   (split_stack_call_*): New insn.
+   (split_stack_cond_call): New expand.
+   (split_stack_cond_call_*): New insn.
+
 2016-02-02  Thomas Schwinge  
 
* omp-builtins.def (BUILT_IN_GOACC_HOST_DATA): Remove.
diff --git a/gcc/common/config/s390/s390-common.c 
b/gcc/common/config/s390/s390-common.c
index 4519c21..1e497e6 100644
--- a/gcc/common/config/s390/s390-common.c
+++ b/gcc/common/config/s390/s390-common.c
@@ -105,6 +105,17 @@ s390_handle_option (struct gcc_options *opts 
ATTRIBUTE_UNUSED,
 }
 }
 
+/* -fsplit-stack uses a field in the TCB, available with glibc-2.23.
+   We don't verify it, since earlier versions just have padding at
+   its place, which works just as well.  */
+
+static bool
+s390_supports_split_stack (bool report ATTRIBUTE_UNUSED,
+  struct gcc_options *opts ATTRIBUTE_UNUSED)
+{
+  return true;
+}
+
 #undef 

New Vietnamese PO file for 'cpplib' (version 6.1-b20160131)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Vietnamese team of translators.  The file is available at:

http://translationproject.org/latest/cpplib/vi.po

(This file, 'cpplib-6.1-b20160131.vi.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: RFA: Add GCC Runtime Library Exception to include/plugin-api.h

[Andrew Pinski]

On Tue, Feb 2, 2016 at 4:23 PM, David Edelsohn  wrote:
> On Tue, Feb 2, 2016 at 5:03 PM, H.J. Lu  wrote:
>> On Tue, Feb 2, 2016 at 1:35 PM, Cary Coutant  wrote:
 include/plugin-api.h defines an ABI between linker and compiler,
 which can be used to implement linker plug-in by any compilers.
 I'd like to add GCC Runtime Library Exception to include/plugin-api.h
 so that the linker plug-in can have non-GPL licenses.
>>>
>>> This is OK with me.
>>>
>>> -cary
>>
>> Here is a patch.  OK for trunk?
>
> You have not explained why this actually is needed and only the FSF
> can agree to license changes.

In fact I think all linker plugins needs to be GPLv3 compatible
because other ld.bfd and ld.gold would have a license violation.
This is the same story as a GCC plugin too.

Thanks,
Andrew

>
> - David

Re: [PATCH] [ARM] PR68532: Fix VUZP and VZIP recognition on big endian

[Charles Baylis]

On 1 February 2016 at 17:14, Kyrill Tkachov  wrote:

> Indeed I see the new passes on armeb-none-eabi.
> However, the new FAILs that I see are ICEs, not just vectorisation failures,
> so they need to be looked at.
>
> The ICEs that I see are:
> FAIL: gcc.dg/torture/vshuf-v4hi.c   -O2  (internal compiler error)
> FAIL: gcc.dg/torture/vshuf-v8qi.c   -O2  (internal compiler error)

Thanks. I hadn't seen these because I wasn't running the "expensive" tests.

> Seems that the code in expr.c asserts that expand_vec_perm returned a
> non-NULL result.

It seems that my implementation of arm_evpc_neon_vuzp doesn't handle
the one vector case correctly. I'm testing a fix.

> I'll look at the patches in more detail, but in the meantime I notice that
> there are some
> GNU style issues that should be resolved, like starting comments with a
> capital letter,
> two spaces after full stop, two spaces between full stop and close comment,
> as well as some
> lines over 80 characters. The check_GNU_style.sh script in the contrib/
> directory can help
> catch some (if not all) of these.

OK, I'll fix those.

> Also, can you please send any follow-up versions of the two patches as
> separate emails,
> so that we can more easily keep track of what's comment goes to which patch.

Will do.

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[ppalka at gcc dot gnu.org]

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

--- Comment #13 from Patrick Palka  ---
(In reply to Patrick Palka from comment #12)
> (In reply to Patrick Palka from comment #11)
> > More reduced test case, that does not depend on -ipa-icf:
> > 
> > struct R
> > {
> >   R (const R&) { }
> > };
> > 
> > __attribute__ ((noreturn)) R f ();
> > 
> > R
> > c ()
> > {
> >   f ();
> > }
> > 
> > Untested fix:
> > 
> > diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> > index ce1e712..e07cd04 100644
> > --- a/gcc/gimplify.c
> > +++ b/gcc/gimplify.c
> > @@ -4830,7 +4830,8 @@ gimplify_modify_expr (tree *expr_p, gimple_seq *pre_p,
> > gimple_seq *post_p,
> > }
> > }
> >notice_special_calls (call_stmt);
> > -  if (!gimple_call_noreturn_p (call_stmt))
> > +  if (!gimple_call_noreturn_p (call_stmt)
> > + || gimple_call_return_slot_opt_p (call_stmt))
> > gimple_call_set_lhs (call_stmt, *to_p);
> >assign = call_stmt;
> >  }
> 
> Actually in light of #c2 this might be a separate but related issue.

It may be better to check

TREE_ADDRESSABLE (TREE_TYPE (*to_p))

instead of checking

gimple_call_return_slot_opt_p (call_stmt)

Because with the latter, we trigger a gimple verification error "LHS in
noreturn call" for the following test case, which utilizes the return-slot
optimization but whose TREE_TYPE in question is not TREE_ADDRESSABLE.

struct R
{
  int x[100];
};

__attribute__ ((noreturn)) R f ();

void
c ()
{
  f ();
}

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #11 from Bill Schmidt  ---
OK, yes, that looks correct.  Thanks for the clarification!  I had missed that
statement.

Re: RFA: Add GCC Runtime Library Exception to include/plugin-api.h

[H.J. Lu]

On Tue, Feb 2, 2016 at 4:23 PM, David Edelsohn  wrote:
> On Tue, Feb 2, 2016 at 5:03 PM, H.J. Lu  wrote:
>> On Tue, Feb 2, 2016 at 1:35 PM, Cary Coutant  wrote:
 include/plugin-api.h defines an ABI between linker and compiler,
 which can be used to implement linker plug-in by any compilers.
 I'd like to add GCC Runtime Library Exception to include/plugin-api.h
 so that the linker plug-in can have non-GPL licenses.
>>>
>>> This is OK with me.
>>>
>>> -cary
>>
>> Here is a patch.  OK for trunk?
>
> You have not explained why this actually is needed and only the FSF
> can agree to license changes.
>

Here is an example of linker plugin without using GCC:

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/testplug.c;h=cec947c51c44e7e4334036ecfe96392eb7c32643;hb=HEAD

I'd like to put such plugin under a non-GPL license.

As I understand, Cary, as the contributor of include/plugin-api.h,
may release it under a different license.  Of course, changing license
of include/plugin-api.h in GCC source tree may need FSF approval.
Should we ask FSF to get an approval?


-- 
H.J.

[Bug tree-optimization/67282] Wrong code with -floop-nest-optimize

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
Are gcc 5 and 6 in your setup linked against different versions of ISL? In my
case, it was 0.15 for all installed gcc versions back in December and 0.16, for
all of them as well, as for now.

[committed, PATCH] Add IA MCU tests for passing/returning of empty structures/unions

[H.J. Lu]

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 8277dff..afe4720 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2016-02-02  H.J. Lu  
+
+   * gcc.target/i386/iamcu/test_empty_structs_and_unions.c: New test.
+
 2016-02-02  James Norris  
 
* c-c++-common/goacc/routine-5.c: Add tests.
diff --git 
a/gcc/testsuite/gcc.target/i386/iamcu/test_empty_structs_and_unions.c 
b/gcc/testsuite/gcc.target/i386/iamcu/test_empty_structs_and_unions.c
new file mode 100644
index 000..15209e0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/iamcu/test_empty_structs_and_unions.c
@@ -0,0 +1,61 @@
+/* This tests passing and returning of empty structures and unions.  */
+
+#include "defines.h"
+#include "args.h"
+
+struct IntegerRegisters iregbits = { ~0, ~0, ~0, ~0, ~0, ~0 };
+struct IntegerRegisters iregs;
+unsigned int num_iregs;
+
+struct empty_struct
+{
+};
+
+struct empty_struct
+check_struct_passing(struct empty_struct s0 ATTRIBUTE_UNUSED,
+struct empty_struct s1 ATTRIBUTE_UNUSED,
+int i0 ATTRIBUTE_UNUSED)
+{
+  struct empty_struct s;
+  check_int_arguments;
+  return s;
+}
+
+#define check_struct_passing WRAP_CALL(check_struct_passing)
+
+union empty_union
+{
+};
+
+union empty_union
+check_union_passing(union empty_union u0 ATTRIBUTE_UNUSED,
+   union empty_union u1 ATTRIBUTE_UNUSED,
+   int i0 ATTRIBUTE_UNUSED)
+{
+  union empty_union u;
+  check_int_arguments;
+  return u;
+}
+
+#define check_union_passing WRAP_CALL(check_union_passing)
+
+int
+main (void)
+{
+  struct empty_struct s;
+  union empty_union u;
+
+  clear_struct_registers;
+  iregs.I0 = 32;
+  num_iregs = 1;
+  clear_int_hardware_registers;
+  check_union_passing(u,u,32);
+
+  clear_struct_registers;
+  iregs.I0 = 33;
+  num_iregs = 1;
+  clear_int_hardware_registers;
+  check_struct_passing(s,s,33);
+
+  return 0;
+}

[PATCH] Fix c/69643, named address space wrong-code

[Richard Henderson]

In gimple_fold_indirect_ref, we STRIP_NOPS, find the ADDR_EXPR, and fold 
everything away.


I can't imagine it ever being correct to drop an address space change between 
pointers, so I've modified tree_nop_conversion_p.  Anything else seems to 
require more checks every places we use STRIP_NOPS.


Ok?


r~
diff --git a/gcc/testsuite/gcc.target/i386/addr-space-4.c 
b/gcc/testsuite/gcc.target/i386/addr-space-4.c
new file mode 100644
index 000..3e0966d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/addr-space-4.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+/* { dg-final { scan-assembler "gs:" } } */
+
+#define uintptr_t __SIZE_TYPE__
+
+struct S { int a, b, c; };
+
+extern struct S __seg_gs s;
+
+int foo (void)
+{
+  int r;
+  r = s.c;
+  return r;
+}
diff --git a/gcc/testsuite/gcc.target/i386/addr-space-5.c 
b/gcc/testsuite/gcc.target/i386/addr-space-5.c
new file mode 100644
index 000..4f73f95
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/addr-space-5.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+/* { dg-final { scan-assembler "gs:" } } */
+
+#define uintptr_t __SIZE_TYPE__
+
+struct S { int a, b, c; };
+
+extern struct S s;
+
+int ct_state3 (void)
+{
+  int r;
+  r = *((int __seg_gs *) (uintptr_t) );
+  return r;
+}
diff --git a/gcc/tree.c b/gcc/tree.c
index fa7646b..07cb9d9 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -12219,6 +12219,23 @@ block_ultimate_origin (const_tree block)
 bool
 tree_nop_conversion_p (const_tree outer_type, const_tree inner_type)
 {
+  /* Do not strip casts into or out of differing address spaces.  */
+  if (POINTER_TYPE_P (outer_type)
+  && TYPE_ADDR_SPACE (TREE_TYPE (outer_type)) != ADDR_SPACE_GENERIC)
+{
+  if (!POINTER_TYPE_P (inner_type)
+ || (TYPE_ADDR_SPACE (TREE_TYPE (outer_type))
+ != TYPE_ADDR_SPACE (TREE_TYPE (inner_type
+   return false;
+}
+  else if (POINTER_TYPE_P (inner_type)
+  && TYPE_ADDR_SPACE (TREE_TYPE (inner_type)) != ADDR_SPACE_GENERIC)
+{
+  /* We already know that outer_type is not a pointer with
+a non-generic address space.  */
+  return false;
+}
+
   /* Use precision rather then machine mode when we can, which gives
  the correct answer even for submode (bit-field) types.  */
   if ((INTEGRAL_TYPE_P (outer_type)

[Bug fortran/69514] ICE with nested array constructor

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
Test case from comment 0 can be reduced to e.g.

$ cat z3.f90
program p
   real, parameter :: w(2) = [real :: 0, 3.0*[real :: 2]]
   print *, w
end program

$ gfortran-6 -c z3.f90
f951: internal compiler error: Segmentation fault


Another variation is to revers operands.
As known, this compiles and runs, but gives WRONG results.

$ cat z4.f90
program p
   real, parameter :: w(2) = [real :: 0, [real :: 2]*3.0]
   print *, w
end program

$ gfortran-6 z4.f90
$ a.out
   0.   0.


Analogous for other operations, other intrinsic types, other 
combinations - look up especially in attached files of pr66193.
Some variants segfault, some compile and run silently wrong.

This theme is known from pr66193.

[Bug target/69634] [6 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fschedule-insns -fno-tree-vrp @ i686

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started with r230216.  Will have a look.

[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2

[rth at gcc dot gnu.org]

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

--- Comment #5 from Richard Henderson  ---
(In reply to Andrey Belevantsev from comment #4)
> Created attachment 37550 [details]
> proposed patch
> 
> The problem here is readonly dependence contexts in selective scheduler. 
> We're trying to cache the effect of initializing a dependence context with
> remembering that context and setting a readonly bit on it.  When first
> moving the insn 43 with REG_ARGS_SIZE note through the insn 3 (a simple eax
> set) we also set the last_args_size field of the context.  Later, when we
> make a copy of insn 43 and try to move it again through insn 3, we take the
> cached dependency context and notice the (fake) dep with last_args_size
> insn, which is the old insn 43.  Then the assert saying that we should be
> able to lift the bookkeeping copy up the same way as we did with the
> original insn breaks.

If you're going to make two attempts to move insn 43 past insn 3,
and you've cached stuff from the previous attempt, it seems to me
the bug is elsewhere in not backing out the cached stuff properly.
Just ignoring the dependency the second time around seems like a
source of bugs.

But I freely admit I don't understand the caching going on here.  

> Richard, is it safe to make copies of REG_ARGS_SIZE insns?

In general it should be ok, assuming that you validate everything
else about where you place the insn.

E.g. the insn 43 here, which decrements the stack.  So long as all
paths to the post-dominated call or ARGS_SIZE insn see exactly one
copy, everything will be ok.

[Bug target/69461] [6 Regression] ICE in lra_set_insn_recog_data, at lra.c:964

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Assignee|aoliva at gcc dot gnu.org  |vmakarov at gcc dot 
gnu.org

--- Comment #12 from Alexandre Oliva  ---
Vlad, thanks for taking this over.  Let me just point out, just in case you
missed, that I believe it is important for any register allocator to test
HARD_REGNO_MODE_OK, and that AFAICT we were not doing that.  Please let me know
if I'm mistaken.  Thanks,

New Ukrainian PO file for 'cpplib' (version 6.1-b20160131)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Ukrainian team of translators.  The file is available at:

http://translationproject.org/latest/cpplib/uk.po

(This file, 'cpplib-6.1-b20160131.uk.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Go patch committed: Unpack method names when sorting them

[Ian Lance Taylor]

When using type reflection, you occasionally need to know the order of
a type's methods.  The order is simply an alphabetical sort.
Unfortunately, gccgo was not unpacking names before sorting them,
meaning that a type with a combination of exported and unexported
methods would have them in the wrong order.  This patch fixes the
problem.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 232892)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-8dce33f24dd3a34e3574c1d2604428586b63c1aa
+a408bef550251926c28673818db2c64302faac1d
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc  (revision 232855)
+++ gcc/go/gofrontend/types.cc  (working copy)
@@ -2307,7 +2307,10 @@ class Sort_methods
   bool
   operator()(const std::pair& m1,
 const std::pair& m2) const
-  { return m1.first < m2.first; }
+  {
+return (Gogo::unpack_hidden_name(m1.first)
+   < Gogo::unpack_hidden_name(m2.first));
+  }
 };
 
 // Return a composite literal for the type method table for this type.
@@ -7684,7 +7687,8 @@ Interface_type::get_backend_methods(Gogo
   mfields[i].location = loc;
 
   // Sanity check: the names should be sorted.
-  go_assert(p->name() > last_name);
+  go_assert(Gogo::unpack_hidden_name(p->name())
+   > Gogo::unpack_hidden_name(last_name));
   last_name = p->name();
 }
 
@@ -10489,7 +10493,10 @@ struct Typed_identifier_list_sort
  public:
   bool
   operator()(const Typed_identifier& t1, const Typed_identifier& t2) const
-  { return t1.name() < t2.name(); }
+  {
+return (Gogo::unpack_hidden_name(t1.name())
+   < Gogo::unpack_hidden_name(t2.name()));
+  }
 };
 
 void

[Bug target/69648] New: wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[zsojka at seznam dot cz]

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

Bug ID: 69648
   Summary: wrong code with -O -mtune=winchip-c6 -fPIC
-fexpensive-optimizations -msse4 @ i686
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: i686-pc-linux-gnu

Created attachment 37563
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37563=edit
reduced testcase

Output:
$ i686-pc-linux-gnu-gcc -v  
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-i686/bin/i686-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-233030-checking-yes-rtl-df-nographite-i686/bin/../libexec/gcc/i686-pc-linux-gnu/6.0.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=i686-pc-linux-gnu --with-ld=/usr/bin/i686-pc-linux-gnu-ld
--with-as=/usr/bin/i686-pc-linux-gnu-as --with-sysroot=/usr/i686-pc-linux-gnu
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-233030-checking-yes-rtl-df-nographite-i686
Thread model: posix
gcc version 6.0.0 20160201 (experimental) (GCC) 
$ i686-pc-linux-gnu-gcc -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations
-msse4 testcase.c -static
$ ./a.out 
Segmentation fault

(gdb) disassemble
...
   0x08048d6d <+369>:   movd   %eax,%xmm0
   0x08048d71 <+373>:   mov0x3c(%esp),%eax
=> 0x08048d75 <+377>:   pinsrw $0x1,-0x28514(%eax),%xmm0
   0x08048d7e <+386>:   pextrd $0x3,%xmm1,%eax
   0x08048d84 <+392>:   movd   -0x2851c(%ecx),%xmm1
...
(gdb) info reg
eax0x2  2

The value at 0x3c(%esp) is used uninitialised.
The failure sometimes disappears, because even though the stack contains
garbage, it can be dereferenced (it seems so).

[Bug target/69644] ICE with -O on __sync_bool_compare_and_swap with short in extract_insn, at recog.c:2286

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

Untested fix.  It ICEs on powerpc64 big endian too, you just need -mcpu=power8
to trigger it.

[Bug c/69616] New: optimization of 8 movb

[izaberina at gmail dot com]

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

Bug ID: 69616
   Summary: optimization of 8 movb
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izaberina at gmail dot com
  Target Milestone: ---

I'm on arch linux on x86_64, using gcc 5.3.0.
From this code:

char tape[65536];
void f() {
tape[0] = 0;
tape[1] = 0;
tape[2] = 0;
tape[3] = 0;
tape[4] = 0;
tape[5] = 0;
tape[6] = 0;
tape[7] = 0;
}

gcc produces 8 movb at any -O level, while clang produces 1 movq.

Why is that not being optimized?

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-5.3.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 5.3.0 (GCC)

[Bug target/69532] FAIL: gcc.target/arm/{vect-,}fmaxmin.c execution test on armv7

[david.sherwood at arm dot com]

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

--- Comment #4 from david.sherwood at arm dot com ---
(In reply to vries from comment #3)
> Also for the non-vect version:
> ...
> FAIL: gcc.target/arm/fmaxmin.c execution test
> ...

Hi, if you are not already fixing this, I can take a look if you want?

[Bug target/69616] optimization of 8 movb

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-02
 CC||trippels at gcc dot gnu.org
  Component|c   |target
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
https://goo.gl/k9lDZQ

[Bug tree-optimization/69615] 0 to limit signed range checks don't always use unsigned compare

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-02
 CC||rguenth at gcc dot gnu.org
  Component|rtl-optimization|tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
GCC relies on some fold() routine to do this and we end up with

;; Function r0_to_imax_2 (null)
;; enabled by -tree-original


{
  if ((unsigned int) x <= 2147483645)
{
  ext ();
}
}


;; Function r0_to_imax_1 (null)
;; enabled by -tree-original


{
  if (x >= 0 && x != 2147483647)
{
  ext ();
}
}

;; Function r0_to_imax (null)
;; enabled by -tree-original


{
  if (x >= 0)
{
  ext ();
}


so it seems we are confused by the trick that triggers first, replacing
the <= INT_MAX-1 compare with a != INT_MAX compare and that not being handled
in the range construction code.

Looks like ifcombine doesn't handle it either (maybe_fold_and_comparisons).

void ext(void);
void r0_to_imax_1(int x){ if (x>=0 && x<=(__INT_MAX__-1)) ext(); }

[Bug target/69614] [6 Regression] wrong code with -Os -fno-expensive-optimizations -fschedule-insns -mtpcs-leaf-frame -fira-algorithm=priority @ armv7a

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/69577] [5/6 Regression] wrong code with -fno-forward-propagate -mavx and 128bit arithmetics since r215450

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
(In reply to Uroš Bizjak from comment #6)
> IMO, we should revert r215450, and fix a couple of cases using narrowing
> conversions with gen_lowpart that were introduced after r215450.

Please give me a few days to look at it first.  I still think r215450 is
correct and reverting it is likely to regress code quality.

[Bug target/69616] optimization of 8 movb

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from Richard Biener  ---
Generic BB vectorization could do this, I have partial patches to enable it. 
And we can combine stores on RTL.  We have several duplicate bugreports here.

Re: [PATCH] Fix compile/memory hog in the combiner (PR rtl-optimization/69592)

[Jakub Jelinek]

On Tue, Feb 02, 2016 at 12:50:39AM +0100, Bernd Schmidt wrote:
> On 02/01/2016 09:34 PM, Jakub Jelinek wrote:
> >On the following testcase we completely uselessly consume about 5.5GB
> >of RAM and lots of compile time.  The problem is the code to avoid
> >exponential behavior of nonzero_bits/num_sign_bit_copies on binary
> >arithmetics rtxes, which causes us to recurse even when handling
> >of those rtxes is going to ignore those arguments.
> >So, this patch limits those only to the cases where we are going
> >to recurse on both arguments, for rtxes where we don't look at arguments
> >at all or where we only recurse on a single arguments it doesn't make
> >sense.  On the testcase, one of the rtxes where the new predicates
> >return false but ARITHMETIC_P is true, is COMPARE, in particular
> >(compare:CCC (plus (x) (y)) (x)), where it is known even without
> >looking at the operands that only one bit is possibly non-zero and
> >number of sign bit copies is always 1.  But without the patch we
> >needlessly recurse on x, which is set by another similar operation etc.
> 
> Hmm, so the code we have to eliminate performance problems is itself causing
> them?

Yes.

> I don't see any code handling COMPARE in nonzero_bits1, only the various
> EQ/NE/etc. codes.

Right.

> I think I have a slight preference for listing the cases where we know we
> can avoid the exponential behaviour workaround - i.e. just test for compares
> and return false for them. Otherwise someone might add another of the
> arithmetic codes to nonzero_bits without noticing they have to adjust this
> function as well.

The problem is that there are more codes that aren't handled and thus
listing those that need to be handled is shorter and IMO more maintainable.
There are 32 ARITHMETIC_P codes, and nonzero_bits1 handles by recursing on
both operands 14 of them, and num_signed_bit_copies1 only 10.

I wonder if it wouldn't be better to pass around some structure, containing
for the common case fixed size cache and perhaps fall back to hash_map if
there are more calls to cache than that.  Plus perhaps a recursion depth, so
that we avoid other pathological cases.

Jakub

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

[jirislaby at gmail dot com]

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

--- Comment #5 from Jiri Slaby  ---
(In reply to Jakub Jelinek from comment #4)
> What gcc options are you using on the preprocessed source to trigger this?

By default this:
gcc-6 -nostdinc -fno-strict-aliasing -fno-common -std=gnu89 -mno-sse -mno-mmx
-mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387
-mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic
-mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -pipe
-fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0 
-fstack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer
-fno-optimize-sibling-calls -fno-var-tracking-assignments
-fasynchronous-unwind-tables -pg -mfentry  -fno-inline-functions-called-once 
-fno-strict-overflow -fconserve-stack  -fsanitize=kernel-address
-fasan-shadow-offset=0xdc00 --param asan-stack=1 --param
asan-globals=1 --param asan-instrumentation-with-call-threshold=1
-fsanitize-coverage=trace-pc   -S -o - af_netlink.i

And this simplified one produces the same around the call:
gcc-6 -nostdinc -O2 -std=gnu89   -fsanitize=kernel-address
-fasan-shadow-offset=0xdc00 --param asan-stack=1 --param
asan-globals=1 --param asan-instrumentation-with-call-threshold=1
-fsanitize-coverage=trace-pc   -S -o - af_netlink.i

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

[jirislaby at gmail dot com]

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

--- Comment #9 from Jiri Slaby  ---
(In reply to Dmitry Vyukov from comment #8)
> First of all, are you sure that r12 is not 0 before the call?

Yes.

> Deference of 0xdc00 is how KASAN reacts on NULL deref, it does
> shadow check before the memory accesses. If original address is NULL, the
> shadow check will go to 0xdc00. I see such GPFs quite
> frequently, so that's what I would assume first.

I know, I thought so first too. But later, I debugged that to a gcc bug :).

> If you just switched to gcc6, then it can be some latent bug (undefined
> behavior), which started to fire with a new compiler.

W/ CONFIG_KCOV=n (i.e. no -fsanitize-coverage), it works, apparently.

[Bug c++/69627] [6 Regression] Conditional jump or move depends on uninitialised value(s) in (anonymous namespace)::layout::get_state_at_point

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

PR 69577: Invalid RA of destination subregs

[Richard Sandiford]

In PR 69577 we have:

  A: (set (reg:V2TI X) ...)
  B: (set (subreg:TI (reg:V2TI X) 0) ...)

X gets allocated to an AVX register, as usual for V2TI.  The problem is
that the movti for B doesn't then preserve the other half of X, even
though the subreg semantics are supposed to guarantee that.

If instead the same value had been set by:

  A': (set (subreg:TI (reg:V2TI X) 16) ...)
  B: (set (subreg:TI (reg:V2TI X) 0) ...)

the subreg in A' would have prevented the use of AVX registers for X,
since you can't directly access the high part.

IMO these are really the same thing.  An alternative way to view it
is that the original sequence is equivalent to:

  A: (set (reg:V2TI X) ...)
  B1: (set (subreg:TI (reg:V2TI X) 0) ...)
  B2: (set (subreg:TI (reg:V2TI X) 16) (subreg:TI (reg:V2TI X) 16))

in which B2 is a no-op and therefore implicit.  The handling ought
to be the same regardless of whether there is an rtl insn that
explicitly assigns to (subreg:TI (reg:V2TI X) 16).

This patch implements that idea.  Hopefully the comments explain
what's going on.

Tested on x86_64-linux-gnu so far.  Will test on aarch64-linux-gnu and
arm-linux-gnueabihf as well.  OK to install if the additional testing
succeeds?

Thanks,
Richard


diff --git a/gcc/reginfo.c b/gcc/reginfo.c
index 6814eed..afb36aa 100644
--- a/gcc/reginfo.c
+++ b/gcc/reginfo.c
@@ -1244,8 +1244,16 @@ simplifiable_subregs (const subreg_shape )
 static HARD_REG_SET **valid_mode_changes;
 static obstack valid_mode_changes_obstack;
 
+/* Restrict the choice of register for SUBREG_REG (SUBREG) based
+   on information about SUBREG.
+
+   If PARTIAL_DEF, SUBREG is a partial definition of a multipart inner
+   register and we want to ensure that the other parts of the inner
+   register are correctly preserved.  If !PARTIAL_DEF we need to
+   ensure that SUBREG itself can be formed.  */
+
 static void
-record_subregs_of_mode (rtx subreg)
+record_subregs_of_mode (rtx subreg, bool partial_def)
 {
   unsigned int regno;
 
@@ -1256,15 +1264,41 @@ record_subregs_of_mode (rtx subreg)
   if (regno < FIRST_PSEUDO_REGISTER)
 return;
 
+  subreg_shape shape (shape_of_subreg (subreg));
+  if (partial_def)
+{
+  /* The number of independently-accessible SHAPE.outer_mode values
+in SHAPE.inner_mode is GET_MODE_SIZE (SHAPE.inner_mode) / SIZE.
+We need to check that the assignment will preserve all the other
+SIZE-byte chunks in the inner register besides the one that
+includes SUBREG.
+
+In practice it is enough to check whether an equivalent
+SHAPE.inner_mode value in an adjacent SIZE-byte chunk can be formed.
+If the underlying registers are small enough, both subregs will
+be valid.  If the underlying registers are too large, one of the
+subregs will be invalid.
+
+This relies on the fact that we've already been passed
+SUBREG with PARTIAL_DEF set to false.  */
+  unsigned int size = MAX (REGMODE_NATURAL_SIZE (shape.inner_mode),
+  GET_MODE_SIZE (shape.outer_mode));
+  gcc_checking_assert (size < GET_MODE_SIZE (shape.inner_mode));
+  if (shape.offset >= size)
+   shape.offset -= size;
+  else
+   shape.offset += size;
+}
+
   if (valid_mode_changes[regno])
 AND_HARD_REG_SET (*valid_mode_changes[regno],
- simplifiable_subregs (shape_of_subreg (subreg)));
+ simplifiable_subregs (shape));
   else
 {
   valid_mode_changes[regno]
= XOBNEW (_mode_changes_obstack, HARD_REG_SET);
   COPY_HARD_REG_SET (*valid_mode_changes[regno],
-simplifiable_subregs (shape_of_subreg (subreg)));
+simplifiable_subregs (shape));
 }
 }
 
@@ -1277,7 +1311,7 @@ find_subregs_of_mode (rtx x)
   int i;
 
   if (code == SUBREG)
-record_subregs_of_mode (x);
+record_subregs_of_mode (x, false);
 
   /* Time for some deep diving.  */
   for (i = GET_RTX_LENGTH (code) - 1; i >= 0; i--)
@@ -1304,8 +1338,15 @@ init_subregs_of_mode (void)
 
   FOR_EACH_BB_FN (bb, cfun)
 FOR_BB_INSNS (bb, insn)
-  if (NONDEBUG_INSN_P (insn))
-find_subregs_of_mode (PATTERN (insn));
+  {
+   if (NONDEBUG_INSN_P (insn))
+ find_subregs_of_mode (PATTERN (insn));
+   df_ref def;
+   FOR_EACH_INSN_DEF (def, insn)
+ if (DF_REF_FLAGS_IS_SET (def, DF_REF_PARTIAL)
+ && df_read_modify_subreg_p (DF_REF_REG (def)))
+   record_subregs_of_mode (DF_REF_REG (def), true);
+  }
 }
 
 const HARD_REG_SET *
diff --git a/gcc/testsuite/gcc.target/i386/pr69577.c 
b/gcc/testsuite/gcc.target/i386/pr69577.c
new file mode 100644
index 000..d680539
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr69577.c
@@ -0,0 +1,25 @@
+/* { dg-do run } */
+/* { dg-require-effective-target avx } */
+/* { dg-require-effective-target int128 } */
+/* { dg-options "-O -fno-forward-propagate -fno-split-wide-types -mavx" } */
+

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Bernd Schmidt  ---
Ah, of course.

 804856f:   df ec   fucomip %st(4),%st

pc 0x804856f0x804856f 
st00.5019607843137254902230771913540508 (raw
0x3ffe8080808080808081)
st11(raw 0x3fff8000)
st20.2509803921568627451115385956770254 (raw
0x3ffd8080808080808081)
st30(raw 0x)
st40.5019607843137254832299731788225472 (raw
0x3ffe8080808080808000)

An equality comparison of floating point numbers, on x87. One of those was just
loaded from a stack slot, the other was kept in a register the whole time.

This code needs -ffloat-store, or -mpc64, when compiled for 32-bit x86.

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

[dvyukov at google dot com]

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

--- Comment #16 from Dmitry Vyukov  ---
> Could you please push that to the syzkaller tree [1] then?

Sorry, syzkaller page referred to outdated patch. I was hoping that Andrew will
take it soon, so that I can update the link to a more respected location.
Updated now:
https://github.com/dvyukov/linux/commit/33787098ffaaa83b8a7ccf519913ac5fd6125931

If you will have any other issue feel free to contact
syzkal...@googlegroups.com.

Re the original issue.

We could call a special __sanitizer_cov_trace_pc_special callback which would
save/restore all registers when a file is compiled with -fcall-saved*. But it
probably does not worth it while we have a single case.

We could also add a finer-grained function attibute which disables kcov
instrumentation of a single function. But the same reasoning applies.

[Bug tree-optimization/69599] [6 Regression] libgomp.c fipa-pta tests compiled with -flto -flto-partition=max fail in execution

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|libgomp.c fipa-pta tests|[6 Regression] libgomp.c
   |compiled with -flto |fipa-pta tests compiled
   |-flto-partition=max fail in |with -flto
   |execution   |-flto-partition=max fail in
   ||execution

--- Comment #2 from vries at gcc dot gnu.org ---
omp-nested-2.c is omp-nested-1.c with -fipa-pta.

omp-nested-1.c with -fipa-pta -flto -flto-partition=max passes for
gcc-5-branch.

So, marking as 6 regression.

[PATCH] s390: Add -fsplit-stack support

[Marcin Kościelnicki]

libgcc/ChangeLog:

* config.host: Use t-stack and t-stack-s390 for s390*-*-linux.
* config/s390/morestack.S: New file.
* config/s390/t-stack-s390: New file.
* generic-morestack.c (__splitstack_find): Add s390-specific code.

gcc/ChangeLog:

* common/config/s390/s390-common.c (s390_supports_split_stack):
New function.
(TARGET_SUPPORTS_SPLIT_STACK): New macro.
* config/s390/s390-protos.h: Add s390_expand_split_stack_prologue.
* config/s390/s390.c (struct machine_function): New field
split_stack_varargs_pointer.
(s390_register_info): Mark r12 as clobbered if it'll be used as temp
in s390_emit_prologue.
(s390_emit_prologue): Use r12 as temp if r1 is taken by split-stack
vararg pointer.
(morestack_ref): New global.
(SPLIT_STACK_AVAILABLE): New macro.
(s390_expand_split_stack_prologue): New function.
(s390_expand_split_stack_call): New function.
(s390_live_on_entry): New function.
(s390_va_start): Use split-stack vararg pointer if appropriate.
(s390_reorg): Lower the split-stack pseudo-insns.
(s390_asm_file_end): Emit the split-stack note sections.
(TARGET_EXTRA_LIVE_ON_ENTRY): New macro.
* config/s390/s390.md (UNSPEC_STACK_CHECK): New unspec.
(UNSPECV_SPLIT_STACK_CALL): New unspec.
(UNSPECV_SPLIT_STACK_SIBCALL): New unspec.
(UNSPECV_SPLIT_STACK_MARKER): New unspec.
(split_stack_prologue): New expand.
(split_stack_call): New expand.
(split_stack_call_*): New insn.
(split_stack_cond_call): New expand.
(split_stack_cond_call_*): New insn.
(split_stack_space_check): New expand.
(split_stack_sibcall): New expand.
(split_stack_sibcall_*): New insn.
(split_stack_cond_sibcall): New expand.
(split_stack_cond_sibcall_*): New insn.
(split_stack_marker): New insn.
---
Here we go.  I've also removed the "see below", since I don't really
see anything below...

 gcc/ChangeLog|  37 +++
 gcc/common/config/s390/s390-common.c |  14 +
 gcc/config/s390/s390-protos.h|   1 +
 gcc/config/s390/s390.c   | 323 ++-
 gcc/config/s390/s390.md  | 177 ++
 libgcc/ChangeLog |   7 +
 libgcc/config.host   |   4 +-
 libgcc/config/s390/morestack.S   | 609 +++
 libgcc/config/s390/t-stack-s390  |   2 +
 libgcc/generic-morestack.c   |   4 +
 10 files changed, 1171 insertions(+), 7 deletions(-)
 create mode 100644 libgcc/config/s390/morestack.S
 create mode 100644 libgcc/config/s390/t-stack-s390

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 9a2cec8..af86079 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,40 @@
+2016-02-02  Marcin Kościelnicki  
+
+   * common/config/s390/s390-common.c (s390_supports_split_stack):
+   New function.
+   (TARGET_SUPPORTS_SPLIT_STACK): New macro.
+   * config/s390/s390-protos.h: Add s390_expand_split_stack_prologue.
+   * config/s390/s390.c (struct machine_function): New field
+   split_stack_varargs_pointer.
+   (s390_register_info): Mark r12 as clobbered if it'll be used as temp
+   in s390_emit_prologue.
+   (s390_emit_prologue): Use r12 as temp if r1 is taken by split-stack
+   vararg pointer.
+   (morestack_ref): New global.
+   (SPLIT_STACK_AVAILABLE): New macro.
+   (s390_expand_split_stack_prologue): New function.
+   (s390_expand_split_stack_call): New function.
+   (s390_live_on_entry): New function.
+   (s390_va_start): Use split-stack vararg pointer if appropriate.
+   (s390_reorg): Lower the split-stack pseudo-insns.
+   (s390_asm_file_end): Emit the split-stack note sections.
+   (TARGET_EXTRA_LIVE_ON_ENTRY): New macro.
+   * config/s390/s390.md (UNSPEC_STACK_CHECK): New unspec.
+   (UNSPECV_SPLIT_STACK_CALL): New unspec.
+   (UNSPECV_SPLIT_STACK_SIBCALL): New unspec.
+   (UNSPECV_SPLIT_STACK_MARKER): New unspec.
+   (split_stack_prologue): New expand.
+   (split_stack_call): New expand.
+   (split_stack_call_*): New insn.
+   (split_stack_cond_call): New expand.
+   (split_stack_cond_call_*): New insn.
+   (split_stack_space_check): New expand.
+   (split_stack_sibcall): New expand.
+   (split_stack_sibcall_*): New insn.
+   (split_stack_cond_sibcall): New expand.
+   (split_stack_cond_sibcall_*): New insn.
+   (split_stack_marker): New insn.
+
 2016-02-02  Thomas Schwinge  
 
* omp-builtins.def (BUILT_IN_GOACC_HOST_DATA): Remove.
diff --git a/gcc/common/config/s390/s390-common.c 
b/gcc/common/config/s390/s390-common.c
index 4519c21..1e497e6 100644
--- a/gcc/common/config/s390/s390-common.c
+++ b/gcc/common/config/s390/s390-common.c
@@ -105,6 +105,17 

[Bug c++/69627] New: [6 Regression] Conditional jump or move depends on uninitialised value(s) in (anonymous namespace)::layout::get_state_at_point

[marxin at gcc dot gnu.org]

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

Bug ID: 69627
   Summary: [6 Regression] Conditional jump or move depends on
uninitialised value(s) in (anonymous
namespace)::layout::get_state_at_point
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello.

$ cat tc2.c
typedef float __m128;
void test_1 () {
__m128 myvec[2];
int const *ptr;
myvec[1]/ptr;
}

$ valgrind --leak-check=yes --trace-children=yes ./gcc/xgcc -B gcc tc2.c

produces:
==14470== Conditional jump or move depends on uninitialised value(s)
==14470==at 0x1901E24: (anonymous
namespace)::layout::get_state_at_point(int, int, int, int, (anonymous
namespace)::point_state*) (diagnostic-show-locus.c:725)
==14470==by 0x1901861: (anonymous
namespace)::layout::print_source_line(int, (anonymous namespace)::line_bounds*)
(diagnostic-show-locus.c:561)
==14470==by 0x190210A: diagnostic_show_locus(diagnostic_context*,
diagnostic_info const*) (diagnostic-show-locus.c:835)
==14470==by 0x8B50E6: c_diagnostic_finalizer(diagnostic_context*,
diagnostic_info*) (c-opts.c:167)
==14470==by 0x18FEBCC: diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) (diagnostic.c:800)
==14470==by 0x18FFF96: error_at_rich_loc(rich_location*, char const*, ...)
(diagnostic.c:1173)
==14470==by 0x85E415: binary_op_error(rich_location*, tree_code,
tree_node*, tree_node*) (c-common.c:3865)
==14470==by 0x7FF1E0: build_binary_op(unsigned int, tree_code, tree_node*,
tree_node*, int) (c-typeck.c:11577)
==14470==by 0x7DF958: parser_build_binary_op(unsigned int, tree_code,
c_expr, c_expr) (c-typeck.c:3515)
==14470==by 0x81D970: c_parser_binary_expression(c_parser*, c_expr*,
tree_node*) (c-parser.c:6636)
==14470==by 0x81C27B: c_parser_conditional_expression(c_parser*, c_expr*,
tree_node*) (c-parser.c:6279)
==14470==by 0x81BF8B: c_parser_expr_no_commas(c_parser*, c_expr*,
tree_node*) (c-parser.c:6196)
==14470== 
==14470== Conditional jump or move depends on uninitialised value(s)
==14470==at 0x1901E24: (anonymous
namespace)::layout::get_state_at_point(int, int, int, int, (anonymous
namespace)::point_state*) (diagnostic-show-locus.c:725)
==14470==by 0x190199F: (anonymous
namespace)::layout::print_annotation_line(int, (anonymous
namespace)::line_bounds) (diagnostic-show-locus.c:603)
==14470==by 0x1902129: diagnostic_show_locus(diagnostic_context*,
diagnostic_info const*) (diagnostic-show-locus.c:837)
==14470==by 0x8B50E6: c_diagnostic_finalizer(diagnostic_context*,
diagnostic_info*) (c-opts.c:167)
==14470==by 0x18FEBCC: diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) (diagnostic.c:800)
==14470==by 0x18FFF96: error_at_rich_loc(rich_location*, char const*, ...)
(diagnostic.c:1173)
==14470==by 0x85E415: binary_op_error(rich_location*, tree_code,
tree_node*, tree_node*) (c-common.c:3865)
==14470==by 0x7FF1E0: build_binary_op(unsigned int, tree_code, tree_node*,
tree_node*, int) (c-typeck.c:11577)
==14470==by 0x7DF958: parser_build_binary_op(unsigned int, tree_code,
c_expr, c_expr) (c-typeck.c:3515)
==14470==by 0x81D970: c_parser_binary_expression(c_parser*, c_expr*,
tree_node*) (c-parser.c:6636)
==14470==by 0x81C27B: c_parser_conditional_expression(c_parser*, c_expr*,
tree_node*) (c-parser.c:6279)
==14470==by 0x81BF8B: c_parser_expr_no_commas(c_parser*, c_expr*,
tree_node*) (c-parser.c:6196)

Thanks,
Martin

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

[jirislaby at gmail dot com]

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

--- Comment #7 from Jiri Slaby  ---
(In reply to Dmitry Vyukov from comment #6)
> Also what gcc version?

$ gcc-6 --version
gcc-6 (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]

> I've tried:
> gcc version 6.0.0 20160105 (experimental) (GCC) 
> $ gcc /tmp/af_netlink.c -c -O2 -fsanitize-coverage=trace-pc
> -fsanitize=kernel-address --param asan-stack=1 --param asan-globals=1
> --param asan-instrumentation-with-call-threshold=1
> -fasan-shadow-offset=0xdc00

With this I see that too:
movq%r12, %rdx
#APP
# 28 "../arch/x86/include/asm/arch_hweight.h" 1
661:
call __sw_hweight32
662:
#...more ALTINST crap
#NO_APP
addl720(%rbx), %eax
shrq$3, %rdx
movl%eax, %r13d
movabsq $-2305847407260205056, %rax
cmpb$0, (%rdx,%rax)

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

[jirislaby at gmail dot com]

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

--- Comment #12 from Jiri Slaby  ---
(In reply to Jiri Slaby from comment #11)
> __sw_hweight32 changes only retval (rax) and parameter (rdi).

... and rdi is stored to and restored from stack.

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

[dvyukov at google dot com]

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

--- Comment #14 from Dmitry Vyukov  ---
Wait, I already disabled instrumentation of hweight.c for because of this:

+# Kernel does not boot if we instrument this file as it uses custom calling
+# convention (see CONFIG_ARCH_HWEIGHT_CFLAGS).
+KCOV_INSTRUMENT_hweight.o := n

If you apply the latest kcov patch "[PATCH v6] kernel: add kcov code coverage",
it should work.