Re: [PATCH] Fix pr70061

[Jeff Law]

On 03/05/2016 01:02 PM, Richard Henderson wrote:

The problem is that we are emitting copy sequences to edges without caring
for deferred popping of arguments.  Thus when we began emitting code for
the
first block, which in this case starts with a label, we had 32 bytes of
pending stack adjustment, which emit_label flushed.  The ICE is due to the
label not being the first insn in the BB.

There are two equivalent ways to fix this: we can either save/restore
inhibit_defer_pop around these sequences, or we can manually flush any
pending stack adjustment.

This does the latter.  Ok?


r~

z


* tree-outofssa.c (emit_partition_copy): Flush pending stack adjust.
(insert_value_copy_on_edge): Likewise.

* gcc.c-torture/compile/pr70061.c: New test.
I was a bit confused trying to figure out how we got a pending stack 
adjust when we were still in the out-of-ssa pass.  But out-of-ssa can 
call emit_block_copy which can, of course, emit a memcpy.


Similarly, I suspect store_expr can do the same for the 
insert_value_copy_on_edge case.


Ok for the trunk.  Thanks for tracking this down.

jeff

[Bug c++/70112] [lto] Segmentation fault in Libreoffice's program gengal.bin when build with LTO

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-07
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/70112] [lto] Segmentation fault in Libreoffice's program gengal.bin when build with LTO

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
There is too little information to be useful.
At least please build with debugging info enabled and find out
exactly what is going on.
Next build with -fsanitize=undefined to see if any undefined behavior is
invoked.
Or try to add "-fno-lifetime-dse -fno-delete-null-pointer-checks" and see if
the 
issue goes away.

[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[kabel at blackhole dot sk]

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

Marek Behun  changed:

   What|Removed |Added

 CC||kabel at blackhole dot sk

--- Comment #32 from Marek Behun  ---
(In reply to Steffen Hau from comment #31)

Created PR70112

[Bug c++/70112] New: [lto] Segmentation fault in Libreoffice's program gengal.bin when build with LTO

[kabel at blackhole dot sk]

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

Bug ID: 70112
   Summary: [lto] Segmentation fault in Libreoffice's program
gengal.bin when build with LTO
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kabel at blackhole dot sk
  Target Milestone: ---

Created attachment 37882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37882=edit
gengal-backtrace.txt

As Steffen Hau has posted in the comments on PR50394, Libreoffice's program
gengal.bin fails with segmentation fault during compilation of Libreoffice
itself. I have studied it more, and the problem seems with
libreoffice-5.0.5.2/bridges (libgcc3_uno.so), which are "Bridges from various
C++ ABIs, Java JNI, MS .Net to UNO and back.", as described by README.

When I compiled libgcc3_uno.so with LTO disabled, gengal.bin ran successfully.

Attaching gdb's backtrace when segmentation fault.

The problem seems to be in the destructor
bridges::cpp_uno::shared::CppInterfaceProxy::~CppInterfaceProxy()
which is defined in bridges/source/cpp_uno/shared/cppinterfaceproxy.cxx

CppInterfaceProxy::~CppInterfaceProxy()
{}

And also called from there from function freeCppInterfaceProxy:

pThis->~CppInterfaceProxy();

Re: [PATCH] Enable the whole-vector-shift tests for PPC64

[Richard Biener]

On March 7, 2016 2:03:30 AM GMT+01:00, Bill Schmidt 
 wrote:
>Hi,
>
>Anton Blanchard pointed out that we don't currently execute the
>whole-vector-shift tests for PowerPC.  I tested enabling them on
>powerpc64le-unknown-linux-gnu, which resulted in 8 more test successes
>and no additional failures.  I still need to test this on big-endian.
>Assuming no problems there, is this patch ok for trunk?  I suppose
>technically it should be queued up for GCC 7, though it seems harmless
>enough for GCC 6.  Please let me know which you would prefer.

This is OK for gcc 6.

Richard.

>Thanks!
>
>Bill
>
>
>2016-03-06  Bill Schmidt  
>
>   * lib/target-supports.exp
>   (check_effective_target_whole_vector_shift): Enable for PPC64.
>
>
>Index: gcc/testsuite/lib/target-supports.exp
>===
>--- gcc/testsuite/lib/target-supports.exp  (revision 233943)
>+++ gcc/testsuite/lib/target-supports.exp  (working copy)
>@@ -4006,6 +4006,7 @@ proc check_effective_target_whole_vector_shift {
>}
> if { [istarget i?86-*-*] || [istarget x86_64-*-*]
>|| [istarget ia64-*-*]
>|| [istarget aarch64*-*-*]
>+   || [istarget powerpc64*-*-*]
>|| ([check_effective_target_arm32]
>&& [check_effective_target_arm_little_endian])
>|| ([istarget mips*-*-*]

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

[dan.parrot at mail dot com]

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

dan.parrot at mail dot com changed:

   What|Removed |Added

 CC||dan.parrot at mail dot com

--- Comment #1 from dan.parrot at mail dot com ---
Could you provide the options to ./configure which build gcc while allowing
flag -msoft-float and type __float128 to co-exist? Or is changing the code to
allow that combination part of the task here?

I have been unable to configure a build that accepts them (-msoft-float and
__float128) together.

[Bug c++/70111] Internal compiler error on constant enum access

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
From the manual:
   -ftemplate-depth=n
   Set the maximum instantiation depth for template classes to n.  A
limit on the template instantiation depth is needed to detect endless
   recursions during template class instantiation.  ANSI/ISO C++
conforming programs must not rely on a maximum depth greater than 17 (changed
to
   1024 in C++11).  The default value is 900, as the compiler can run
out of stack space before hitting 1024 in some situations.

Re: [gimplefe] [gsoc16] Gimple Front End Project

[Prasad Ghangal]

On 6 March 2016 at 21:13, Richard Biener  wrote:
>
> I'll be willing to mentor this.  Though I'd rather have us starting from 
> scratch and look at having a C-like input language, even piggy-backing on the 
> C frontend maybe.

That's great. I would like to know scope of the project for gsoc so
that I can start preparing for proposal.

>
> Richard.
>

-- 
Thanks and Regards,
Prasad Ghangal

[Bug c/70104] Should give an error when using multiple case value in switch

[np199113 at gmail dot com]

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

--- Comment #2 from Niks  ---
(In reply to Jakub Jelinek from comment #1)
> 'a' || 'A' is 1, so there is no reason to give an error about it.
> The error in the second case is because you have two case labels with the
> same value, 1.  That is not allowed in a switch.

Thank you.!

Re: [RFC PR43721] Optimize a/b and a%b to single divmod call

[Ramana Radhakrishnan]

Hi Prathamesh,

Could you split out the ARM specific portions into a separate patch
please in a patch series?

>@deftypefn {Target Hook} void TARGET_EXPAND_DIVMOD_LIBFUNC (bool 
>@var{unsignedp}, machine_mode @var{mode}, @var{rtx}, @var{rtx}, rtx 
>*@var{quot}, rtx *@var{rem})
>Expand divmod libfunc
>@end deftypefn
>

This could do with some more detail here with respect to the
conditions when a port needs
to define this particular macro.

Based on the discussion it would be good to have an assert for
TARGET_IDIV in the hook
for the ARM port.

i.e gcc_assert (!TARGET_IDIV);


>
># Return 1 if the target supports divmod
>
>proc check_effective_target_divmod { } {
>if { [istarget arm*-*-*] } {
>   return 1
>}
>return 0
>}
>

This will fail test cases in a configuration where a div instruction
exists. If you are looking to
check the transformation - I think you need to check for __ARM_ARCH_EXT_IDIV__
here similar to the way in which we test for FMA or __ARM_FEATURE_UNALIGNED.

Could you please repost with the changes so that I can take another look ?

Otherwise I think this is something we should queue up for GCC 7.

thanks,
Ramana

Re: Please include ada-hurd.diff upstream (try2)

[Matthias Klose]

[adding Eric for review]

On 02.03.2016 00:42, Svante Signell wrote:

Hello,

As time progresses, the ada-hurd.diff patch has now been living in Debian since
gcc-4.6 and is now in gcc-5 and gcc-6. Last try to get it included upstream was
in 2012, and 2014, e.g see
https://gcc.gnu.org/ml/gcc-patches/2012-06/msg0.html
and follow-ups.

Maybe the time has come now for a proper inclusion of Ada/Gnat support in gcc-*
for GNU/Hurd. (Yes, I commit to maintain Ada in gcc for GNU/Hurd in the
foreseeable future, according to my abilities).

Attached is an updated patch, now living e.g. in GNU/Debian versions of gcc-5
and gcc-6.

Please tell me if you need a changelog entry too. And yes, I have already signed
all copyright papers for FSF wrt gcc (and other packages).


yes, please add a ChangeLog entry too.

Matthias

Re: [patch, testsuite, ARM] don't try to execute simd.exp tests on targets without NEON

[Ramana Radhakrishnan]

On Wed, Mar 2, 2016 at 1:33 PM, Andre Vieira (lists)
 wrote:
> On 21/05/15 10:01, Kyrill Tkachov wrote:
>> Hi Sandra,
>>
>> On 21/05/15 06:43, Sandra Loosemore wrote:
>>> This is another patch aimed at fixing bugs relating to trying to execute
>>> NEON code on a target that doesn't support it revealed by my
>>> arm-none-eabi testing on a gazillion different multilibs.  Inspired by
>>> what vect.exp does and my other patch in this group to fix
>>> advsimd-intrinsics.exp, I've hacked simd.exp to test for NEON
>>> compilation and execution support and use set dg-do-what-default to
>>> either "compile" or "run" as appropriate, or skip the whole set of tests
>>> if neither is present.  And, I've removed the explicit "dg-do run" and
>>> arm_neon_ok test (which only tests for compilation support, not
>>> execution support) from all the individual test cases.
>>>
>>> OK to commit?
>>
>> This is ok and there is one less headache with NEON testing :)
>> Thanks,
>> Kyrill
>>
>>>
>>> -Sandra
>>>
>>
> Could we have this backported to the gcc-5-branch? The patch seems to
> apply cleanly and it would clean up testing for simd/neon for gcc-5.


OK.

Ramana
>
> Cheers,
> Andre

Re: [PATCH][ARM] Error out of arm_neon.h if compiling for soft-float ABI

[Ramana Radhakrishnan]

On Mon, Feb 29, 2016 at 5:48 PM, Kyrill Tkachov
 wrote:
> Hi all,
>
> Now that we've moved to pragmas guarding the various intrinsics in
> arm_neon.h I think we should still
> throw a #error if someone tries to include the header while compiling for
> -mfloat-abi=soft.
>
> This gives a more helpful error message when someone has a compiler
> configured --with-float=soft
> and forgets to add an appropriate -mfloat-abi option on the command line.
> Currently we'll just give tons of error messages whereas with this patch we
> just
> show a simple clean message.
>
> Tested on arm. This could be argued to be a user experience regression fix.
> Ok for trunk?


OK.

thanks,
Ramana
>
> Thanks,
> Kyrill
>
> 2016-02-29  Kyrylo Tkachov  
>
> * config/arm/arm_neon.h: Show error if using with soft-float ABI.

Re: [AArch64] Disable pcrelative_literal_loads with fix-cortex-a53-843419

[Ramana Radhakrishnan]

On Tue, Jan 26, 2016 at 2:42 PM, Christophe Lyon
 wrote:
> Hi,
>
> This is a followup to PR63304.
>
> As discussed in bugzilla, this patch disables pcrelative_literal_loads
> when -mfix-cortex-a53-843419 (or its default configure option) is
> used.
>
> I copied the behavior of -mfix-cortex-a53-835769 (e.g. in
> aarch64_can_inline_p), and I have tested by building the Linux kernel
> using -mfix-cortex-a53-843419 and checked that
> R_AARCH64_ADR_PREL_PG_HI21 relocations are not emitted anymore (under
> CONFIG_ARM64_ERRATUM_843419).
>
> For reference, this is motivated by:
> https://bugs.linaro.org/show_bug.cgi?id=1994

I think we need a bug report for this in the GCC bugzilla targeting
GCC 6 and have a reference to that in addition to PR63304 as this is
broken behaviour in gcc trunk with respect to the erratum fixup.

There are 2 solutions to this - one is to put out address constants in
the large memory model with the mov / movk instruction sequences but
then that wouldn't work with older released kernels and require
changes to the kernel loader and the other being this where we turn on
PC relative literal loads for the erratum fixup. I personally think
that this solution is probably sensible during stage4 but I cannot
approve changes to the AArch64 backend.

The only question I have about this implementation in the sources
based on a cursory look at the patch is whether this ends up working
reliably with LTO ?


regards
Ramana

> and further details on Launchpad:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533009
>
> OK for trunk?
>
> Thanks,
>
> Christophe.

Re: [PATCH, ARM] stop changing signedness in PROMOTE_MODE

[Ramana Radhakrishnan]

On Wed, Feb 17, 2016 at 10:20 AM, Christophe Lyon
 wrote:
> On 17 February 2016 at 11:05, Kyrill Tkachov
>  wrote:
>>
>> On 17/02/16 10:03, Christophe Lyon wrote:
>>>
>>> On 15 February 2016 at 12:32, Kyrill Tkachov
>>>  wrote:

 On 04/02/16 08:58, Ramana Radhakrishnan wrote:
>
> On Tue, Jun 30, 2015 at 2:15 AM, Jim Wilson 
> wrote:
>>
>> This is my suggested fix for PR 65932, which is a linux kernel
>> miscompile with gcc-5.1.
>>
>> The problem here is caused by a chain of events.  The first is that
>> the relatively new eipa_sra pass creates fake parameters that behave
>> slightly differently than normal parameters.  The second is that the
>> optimizer creates phi nodes that copy local variables to fake
>> parameters and/or vice versa.  The third is that the ouf-of-ssa pass
>> assumes that it can emit simple move instructions for these phi nodes.
>> And the fourth is that the ARM port has a PROMOTE_MODE macro that
>> forces QImode and HImode to unsigned, but a
>> TARGET_PROMOTE_FUNCTION_MODE hook that does not.  So signed char and
>> short parameters have different in register representations than local
>> variables, and require a conversion when copying between them, a
>> conversion that the out-of-ssa pass can't easily emit.
>>
>> Ultimately, I think this is a problem in the arm backend.  It should
>> not have a PROMOTE_MODE macro that is changing the sign of char and
>> short local variables.  I also think that we should merge the
>> PROMOTE_MODE macro with the TARGET_PROMOTE_FUNCTION_MODE hook to
>> prevent this from happening again.
>>
>> I see four general problems with the current ARM PROMOTE_MODE
>> definition.
>> 1) Unsigned char is only faster for armv5 and earlier, before the sxtb
>> instruction was added.  It is a lose for armv6 and later.
>> 2) Unsigned short was only faster for targets that don't support
>> unaligned accesses.  Support for these targets was removed a while
>> ago, and this PROMODE_MODE hunk should have been removed at the same
>> time.  It was accidentally left behind.
>> 3) TARGET_PROMOTE_FUNCTION_MODE used to be a boolean hook, when it was
>> converted to a function, the PROMOTE_MODE code was copied without the
>> UNSIGNEDP changes.  Thus it is only an accident that
>> TARGET_PROMOTE_FUNCTION_MODE and PROMOTE_MODE disagree.  Changing
>> TARGET_PROMOTE_FUNCTION_MODE is an ABI change, so only PROMOTE_MODE
>> changes to resolve the difference are safe.
>> 4) There is a general principle that you should only change signedness
>> in PROMOTE_MODE if the hardware forces it, as otherwise this results
>> in extra conversion instructions that make code slower.  The mips64
>> hardware for instance requires that 32-bit values be sign-extended
>> regardless of type, and instructions may trap if this is not true.
>> However, it has a set of 32-bit instructions that operate on these
>> values, and hence no conversions are required.  There is no similar
>> case on ARM. Thus the conversions are unnecessary and unwise.  This
>> can be seen in the testcases where gcc emits both a zero-extend and a
>> sign-extend inside a loop, as the sign-extend is required for a
>> compare, and the zero-extend is required by PROMOTE_MODE.
>
> Given Kyrill's testing with the patch and the reasonably detailed
> check of the effects of code generation changes - The arm.h hunk is ok
> - I do think we should make this explicit in the documentation that
> TARGET_PROMOTE_MODE and TARGET_PROMOTE_FUNCTION_MODE should agree and
> better still maybe put in a checking assert for the same in the
> mid-end but that could be the subject of a follow-up patch.
>
> Ok to apply just the arm.h hunk as I think Kyrill has taken care of
> the testsuite fallout separately.

 Hi all,

 I'd like to backport the arm.h from this ( r233130) to the GCC 5
 branch. As the CSE patch from my series had some fallout on x86_64
 due to a deficiency in the AVX patterns that is too invasive to fix
 at this stage (and presumably backport), I'd like to just backport
 this arm.h fix and adjust the tests to XFAIL the fallout that comes
 with not applying the CSE patch. The attached patch does that.

 The code quality fallout on code outside the testsuite is not
 that gread. The SPEC benchmarks are not affected by not applying
 the CSE change, and only a single sequence in a popular embedded
 benchmark
 shows some degradation for -mtune=cortex-a9 in the same way as the
 wmul-1.c and wmul-2.c tests.

 I think that's a fair tradeoff for fixing the wrong code bug on that
 branch.

 Ok to backport r233130 and the 

Re: [PATCH][ARM] PR target/70008

[Ramana Radhakrishnan]

On Mon, Mar 7, 2016 at 3:51 AM, Michael Collison
 wrote:
> New patch that adds the predicate "reg_or_arm_rhs_operand" as suggested by
> Richard. Tested on all arm and thumb targets as before.
>
> Okay for trunk?

Missing comment on the predicate.

Ok, please queue this for GCC 7 with a comment added. I don't think
this is a "regression" worth fixing for GCC 6.



Thanks,
Ramana

>
> 2016-03-07  Michael Collison  
>
> PR target/70008
> * config/arm/predicates.md (reg_or_arm_rhs_operand): New predicate
> that allows registers or immediates if TARGET_ARM.
> * config/arm/arm.md (*subsi3_carryin): Change predicate to
> reg_or_arm_rhs_operand to be consistent with constraints.
>
>
> On 03/03/2016 08:47 PM, Richard Earnshaw (lists) wrote:
>>
>> On 03/03/16 07:23, Michael Collison wrote:
>>>
>>> I have attached a new patch which hopefully address Richard's concerns.
>>> I modified the predicate on operand 1 to to "arm_rhs_operand" to be
>>> consistent with the constraints. I retained the split into two patterns;
>>> one for arm and another for thumb2. I thought this was cleaner.
>>>
>>> Okay for trunk?
>>>
>>> 2016-02-28  Michael Collison  
>>>
>>>  PR target/70008
>>>  * config/arm/arm.md (*subsi3_carryin): Change predicate to
>>>  arm_rhs_operand to be consistent with constraints.
>>>  Only allow pattern for TARGET_ARM.
>>>  * config/arm/thumb2.md (*thumb2_subsi3_carryin): New pattern.
>>>
>> I don't think we need two patterns.  We could share this if we had a new
>> predicate that was called something like reg_or_arm_rhs_operand,  with a
>> rule that's something like:
>>
>>register_operand (op) || (TARGET_ARM && arm_immediate_operand (op))
>>
>> R.
>>>
>>> On 02/29/2016 08:29 AM, Richard Earnshaw (lists) wrote:

 On 29/02/16 11:21, Michael Collison wrote:
>
> On 2/29/2016 4:06 AM, Kyrill Tkachov wrote:
>>
>> Hi Michael,
>>
>> On 29/02/16 04:47, Michael Collison wrote:
>>>
>>> This patches address PR 70008, where a reverse subtract with carry
>>> instruction can be generated in thumb2 mode. It was tested with no
>>> regressions in arm and thumb modes on the following targets:
>>>
>>> arm-none-linux-gnueabi
>>> arm-none-linux-gnuabihf
>>> armeb-none-linux-gnuabihf
>>> arm-none-eabi
>>>
>>> Okay for trunk?
>>>
>>> 2016-02-28  Michael Collison 
>>>
>>>   PR target/70008
>>>   * config/arm/arm.md (*subsi3_carryin): Only match pattern if
>>>   TARGET_ARM due to 'rsc' instruction alternative.
>>>   * config/arm/thumb2.md (*thumb2_subsi3_carryin): New pattern.
>>>
>>>
>> The *subsi3_carrying pattern has the arch attribute:
>>  (set_attr "arch" "*,a")
>>
>> That means that the second alternative that generates the RSC
>> instruction is only enabled
>> for ARM mode. Do you have a testcase where this doesn't happen and
>> this pattern generates
>> the second alternative for Thumb2?
>
> No I don't have a test case; i noticed the pattern when working on the
> overflow project. I did not realize
> that an attribute could affect the matching of an alternative. I will
> close the bug.
>
>> Thanks,
>> Kyrill

 This is all true, but there is a potential performance issue with this
 pattern though, that could lead to sub-optimal code.

 The predicate accepts reg-or-int, but in ARM state only simple
 'const-ok-for-arm' immediates are permitted by the predicates, and in
 thumb code, no immediates are permitted at all.  This could potentially
 result in sub-optimal code due to late splitting of the pattern.  It
 would be better if the predicate understood these limitations and
 restricted immediates accordingly.

 R.

>>>
>>> bugzilla-70008-upstream-v2.patch
>>>
>>>
>>> diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
>>> index e67239d..e6bcd7f 100644
>>> --- a/gcc/config/arm/arm.md
>>> +++ b/gcc/config/arm/arm.md
>>> @@ -867,15 +867,14 @@
>>> (define_insn "*subsi3_carryin"
>>> [(set (match_operand:SI 0 "s_register_operand" "=r,r")
>>> -(minus:SI (minus:SI (match_operand:SI 1 "reg_or_int_operand"
>>> "r,I")
>>> +(minus:SI (minus:SI (match_operand:SI 1 "arm_rhs_operand" "r,I")
>>>   (match_operand:SI 2 "s_register_operand"
>>> "r,r"))
>>> (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
>>> -  "TARGET_32BIT"
>>> +  "TARGET_ARM"
>>> "@
>>>  sbc%?\\t%0, %1, %2
>>>  rsc%?\\t%0, %2, %1"
>>> [(set_attr "conds" "use")
>>> -   (set_attr "arch" "*,a")
>>>  (set_attr "predicable" "yes")
>>>  (set_attr "predicable_short_it" "no")
>>>  (set_attr "type" "adc_reg,adc_imm")]
>>> diff --git a/gcc/config/arm/thumb2.md 

Re: [PATCH][ARM] PR target/70008

[Michael Collison]

New patch that adds the predicate "reg_or_arm_rhs_operand" as suggested 
by Richard. Tested on all arm and thumb targets as before.


Okay for trunk?

2016-03-07  Michael Collison  

PR target/70008
* config/arm/predicates.md (reg_or_arm_rhs_operand): New predicate
that allows registers or immediates if TARGET_ARM.
* config/arm/arm.md (*subsi3_carryin): Change predicate to
reg_or_arm_rhs_operand to be consistent with constraints.

On 03/03/2016 08:47 PM, Richard Earnshaw (lists) wrote:

On 03/03/16 07:23, Michael Collison wrote:

I have attached a new patch which hopefully address Richard's concerns.
I modified the predicate on operand 1 to to "arm_rhs_operand" to be
consistent with the constraints. I retained the split into two patterns;
one for arm and another for thumb2. I thought this was cleaner.

Okay for trunk?

2016-02-28  Michael Collison  

 PR target/70008
 * config/arm/arm.md (*subsi3_carryin): Change predicate to
 arm_rhs_operand to be consistent with constraints.
 Only allow pattern for TARGET_ARM.
 * config/arm/thumb2.md (*thumb2_subsi3_carryin): New pattern.


I don't think we need two patterns.  We could share this if we had a new
predicate that was called something like reg_or_arm_rhs_operand,  with a
rule that's something like:

   register_operand (op) || (TARGET_ARM && arm_immediate_operand (op))

R.

On 02/29/2016 08:29 AM, Richard Earnshaw (lists) wrote:

On 29/02/16 11:21, Michael Collison wrote:

On 2/29/2016 4:06 AM, Kyrill Tkachov wrote:

Hi Michael,

On 29/02/16 04:47, Michael Collison wrote:

This patches address PR 70008, where a reverse subtract with carry
instruction can be generated in thumb2 mode. It was tested with no
regressions in arm and thumb modes on the following targets:

arm-none-linux-gnueabi
arm-none-linux-gnuabihf
armeb-none-linux-gnuabihf
arm-none-eabi

Okay for trunk?

2016-02-28  Michael Collison 

  PR target/70008
  * config/arm/arm.md (*subsi3_carryin): Only match pattern if
  TARGET_ARM due to 'rsc' instruction alternative.
  * config/arm/thumb2.md (*thumb2_subsi3_carryin): New pattern.



The *subsi3_carrying pattern has the arch attribute:
 (set_attr "arch" "*,a")

That means that the second alternative that generates the RSC
instruction is only enabled
for ARM mode. Do you have a testcase where this doesn't happen and
this pattern generates
the second alternative for Thumb2?

No I don't have a test case; i noticed the pattern when working on the
overflow project. I did not realize
that an attribute could affect the matching of an alternative. I will
close the bug.


Thanks,
Kyrill

This is all true, but there is a potential performance issue with this
pattern though, that could lead to sub-optimal code.

The predicate accepts reg-or-int, but in ARM state only simple
'const-ok-for-arm' immediates are permitted by the predicates, and in
thumb code, no immediates are permitted at all.  This could potentially
result in sub-optimal code due to late splitting of the pattern.  It
would be better if the predicate understood these limitations and
restricted immediates accordingly.

R.



bugzilla-70008-upstream-v2.patch


diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index e67239d..e6bcd7f 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -867,15 +867,14 @@
  
  (define_insn "*subsi3_carryin"

[(set (match_operand:SI 0 "s_register_operand" "=r,r")
-(minus:SI (minus:SI (match_operand:SI 1 "reg_or_int_operand" "r,I")
+(minus:SI (minus:SI (match_operand:SI 1 "arm_rhs_operand" "r,I")
  (match_operand:SI 2 "s_register_operand" "r,r"))
(ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
-  "TARGET_32BIT"
+  "TARGET_ARM"
"@
 sbc%?\\t%0, %1, %2
 rsc%?\\t%0, %2, %1"
[(set_attr "conds" "use")
-   (set_attr "arch" "*,a")
 (set_attr "predicable" "yes")
 (set_attr "predicable_short_it" "no")
 (set_attr "type" "adc_reg,adc_imm")]
diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md
index 9925365..79305c5 100644
--- a/gcc/config/arm/thumb2.md
+++ b/gcc/config/arm/thumb2.md
@@ -848,6 +848,20 @@
 (set_attr "type" "multiple")]
  )
  
+(define_insn "*thumb2_subsi3_carryin"

+  [(set (match_operand:SI 0 "s_register_operand" "=r")
+(minus:SI (minus:SI (match_operand:SI 1 "s_register_operand" "r")
+(match_operand:SI 2 "s_register_operand" "r"))
+  (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
+  "TARGET_THUMB2"
+  "@
+   sbc%?\\t%0, %1, %2"
+  [(set_attr "conds" "use")
+   (set_attr "predicable" "yes")
+   (set_attr "predicable_short_it" "no")
+   (set_attr "type" "adc_reg")]
+)
+
  (define_insn "*thumb2_cond_sub"
[(set (match_operand:SI 0 "s_register_operand" "=Ts,Ts")
  (minus:SI (match_operand:SI 1 "s_register_operand" "0,?Ts")



--

[Bug target/69040] cris allmodconfig fails

[hp at gcc dot gnu.org]

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

--- Comment #8 from Hans-Peter Nilsson  ---
Supposedly viable workarounds: omit "-fno-omit-frame-pointer" or use "-O2".

(required and necessary options for observation; omitting any of the
"-f"-options compiles succcessfully: "-Os -march=v10 -fno-strict-aliasing
-fno-delete-null-pointer-checks -fno-omit-frame-pointer
-fno-inline-functions-called-once")

[PATCH] 69517 - [5/6 regression] SEGV on a VLA with excess initializer elements

[Martin Sebor]

GCC 4.9 had added support for C++ VLAs as specified in WG21
document N3639 expected to be included in C++ 14.  However,
WG21 ultimately decided not to include N3639 in C++ 14 and
the G++ support was partially removed in 5.1.  Unfortunately,
the removal rendered some safe albeit erroneous G++ 4.9 code
undefined.  This patch restores the well-defined behavior of
such code by having it throw an exception in response to
the erroneous conditions.

While testing the patch I found a number of other problems in
the G++ support for VLAs, including PR c++/70019 - VLA size
overflow not detected, which was never implemented (not even
in 4.9).  Since this is closely related to the regression
discussed in 69517 the patch also provides that support.

There are a few additional points to note about the patch:

1) It restores the std::bad_array_length exception from N3639,
   even though the class isn't specified by the C++ standard.
   At first I thought that introducing a different (private)
   type would be more appropriate, but in the end couldn't come
   up with a good argument for not keeping the same type.  Using
   the same type also allows programs that rely on the exception
   and that were built with GCC 4.9 to be ported to GCC 6 without
   change.

2) It hardwires a rather arbitrarily restrictive limit of 64 KB
   on the size of the biggest C++ VLA.  (This could stand to be
   improved and made more intelligent, and perhaps integrated
   with stack  checking via -fstack-limit, after the GCC 6
   release.)

3) By throwing an exception for erroneous VLAs the patch largely
   defeats the VLA Sanitizer.  The sanitizer is still useful in
   C++ 98 mode where the N3639 VLA runtime checking is disabled,
   and when exceptions are disabled via -fno-exceptions.
   Disabling  the VLA checking in C++ 98 mode doesn't seem like
   a useful feature, but I didn't feel like reverting what was
   a deliberate decision.

Martin
PR c++/69517 - [5/6 regression] SEGV on a VLA with excess initializer elements
PR c++/70019 - VLA size overflow not detected

gcc/testsuite/ChangeLog:
2016-03-06  Martin Sebor  

	PR c++/69517
	PR c++/70019
	* c-c++-common/ubsan/vla-1.c (main): Catch exceptions.
	* g++.dg/cpp1y/vla11.C: New test.
	* g++.dg/cpp1y/vla12.C: New test.
	* g++.dg/cpp1y/vla13.C: New test.
	* g++.dg/cpp1y/vla14.C: New test.
	* g++.dg/cpp1y/vla3.C: Restore deleted test.
	* g++.dg/ubsan/vla-1.C: Disable exceptions.

gcc/cp/ChangeLog:
2016-03-06  Martin Sebor  

	PR c++/69517
	PR c++/70019
	* decl.c (vla_p, throw_bad_array_length, build_vla_check): New
	functions.
	(check_initializer, cp_finish_decl): Call them.

gcc/doc/ChangeLog:

2016-03-06  Martin Sebor  

	PR c++/69517
	PR c++/70019
	* extend.texi (Variable Length): Document C++ specifics.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 5ec6589..682828c 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -106,6 +106,22 @@ static tree build_cp_library_fn (tree, enum tree_code, tree, int);
 static void store_parm_decls (tree);
 static void initialize_local_var (tree, tree);
 static void expand_static_init (tree, tree);
+static bool vla_p (tree);
+static tree build_vla_check (tree, tree = NULL_TREE, tree = NULL_TREE,
+			 tree = NULL_TREE, offset_int * = 0);
+
+/* Call __cxa_throw_bad_array_length to indicate that the size calculation
+   overflowed.  */
+tree
+throw_bad_array_length (void)
+{
+  tree fn = get_identifier ("__cxa_throw_bad_array_length");
+  if (!get_global_value_if_present (fn, ))
+fn = push_throw_library_fn (fn, build_function_type_list (void_type_node,
+ NULL_TREE));
+
+  return build_cxx_call (fn, 0, NULL, tf_warning_or_error);
+}
 
 /* The following symbols are subsumed in the cp_global_trees array, and
listed here individually for documentation purposes.
@@ -6160,6 +6176,33 @@ check_initializer (tree decl, tree init, int flags, vec **cleanups)
 	  && PAREN_STRING_LITERAL_P (DECL_INITIAL (decl)))
 	warning (0, "array %qD initialized by parenthesized string literal %qE",
 		 decl, DECL_INITIAL (decl));
+
+	  if (TREE_CODE (type) == ARRAY_TYPE
+	  && vla_p (type)
+	  && !processing_template_decl)
+	{
+	  /* Statically check for overflow in VLA bounds and build
+		 an expression that checks whether the VLA is erroneous
+		 at runtime, either due to invalid (runtime) bounds or
+		 due to excess initializers for the runtime bounds.  */
+	  tree check = build_vla_check (TREE_TYPE (decl), init);
+
+	  if (cxx_dialect >= cxx11 && flag_exceptions
+		  && current_function_decl
+		  /* Avoid instrumenting constexpr functions.  Those must
+		 be checked statically, and the (non-constexpr) dynamic
+		 instrumentation would cause them to be rejected.  */
+		  && !DECL_DECLARED_CONSTEXPR_P (current_function_decl))
+		{
+		  /* Use the runtime check only in C++ 11 mode and later
+		 and 

[Bug target/69040] cris allmodconfig fails

[hp at gcc dot gnu.org]

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

--- Comment #7 from Hans-Peter Nilsson  ---
This is a regression for the gcc-5 branch compared to the gcc-4_9-branch at
r233942 (not seeing the error for the same options as observed on the
gcc-5-branch).

[Bug target/69040] cris allmodconfig fails

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/69040] cris allmodconfig fails

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #6 from Hans-Peter Nilsson  ---
I cannot repeat this with the gcc-5 branch at r233997 neither with trunk (gcc6)
at r234014 both built for cris-elf and using "./xgcc -v -B./ -Os -march=v10",
nor
for trunk with "./xgcc -B./ -Os -march=v10 -g -Os -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -Werror=implicit-function-declaration
-Wno-format-security -Wno-maybe-uninitialized -Wframe-larger-than=1024
-Wno-unused-but-set-variable -Wdeclaration-after-statement -Wno-pointer-sign
-Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -std=gnu90
-fno-strict-aliasing -fno-common -fno-delete-null-pointer-checks
-fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining
-fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -fno-inline-functions-called-once
-fno-strict-overflow -fconserve-stack --param allow-store-data-races=0".

I do see it at the above gcc-5 branch revision using the latter options.

[PATCH] Enable the whole-vector-shift tests for PPC64

[Bill Schmidt]

Hi,

Anton Blanchard pointed out that we don't currently execute the
whole-vector-shift tests for PowerPC.  I tested enabling them on
powerpc64le-unknown-linux-gnu, which resulted in 8 more test successes
and no additional failures.  I still need to test this on big-endian.
Assuming no problems there, is this patch ok for trunk?  I suppose
technically it should be queued up for GCC 7, though it seems harmless
enough for GCC 6.  Please let me know which you would prefer.

Thanks!

Bill


2016-03-06  Bill Schmidt  

* lib/target-supports.exp
(check_effective_target_whole_vector_shift): Enable for PPC64.


Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 233943)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -4006,6 +4006,7 @@ proc check_effective_target_whole_vector_shift { }
 if { [istarget i?86-*-*] || [istarget x86_64-*-*]
 || [istarget ia64-*-*]
 || [istarget aarch64*-*-*]
+|| [istarget powerpc64*-*-*]
 || ([check_effective_target_arm32]
 && [check_effective_target_arm_little_endian])
 || ([istarget mips*-*-*]

Re: [committed, libffi] Match upstream soname

[Matthias Klose]

On 05.03.2016 19:28, Richard Henderson wrote:

When I went to apply my symbol versioning patch to upstream,
I discovered that upstream had already bumped their soname to
6.4.0, beyond the bump that I'd applied to gcc to 5.0.0.

So I bumped upstream to 7.0.0, including the symbol versioning,
and this adjusts gcc to match.


Looking at the libffi upstream git repo, I can't find this change upstream, and 
neither mentioned on the libffi mailing list. What am I missing?


Matthias

[Bug target/70079] missed constant propagation in memcpy expansion

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
(In reply to Paolo Bonzini from comment #0)
> movq%rdi, %rcx
> leaq8(%rdi), %rdi
> andq$-8, %rdi ;; 1
> subq%rdi, %rcx;; 2
> subq%rcx, %rsi;; 3
> addl$512, %ecx;; 4
> shrl$3, %ecx  ;; 5
> 
> At 1, rdi = (a + 8) & ~7 = a & ~7 + 8 = a + 8 - (a & 7)
> At 2, rcx = a - rdi = a - a - 8 + (a & 7) = (a & 7) - 8
> At 3, rsi = b - (a & 7) + 8
> At 4, rcx = (a & 7) + 504, which is between 504 and 511
> At 5, rcx is always 31.

It would seem %rsi is still alive after this, so the %rcx input to "3"
has to be computed, which takes more than one insn so there is no way
combine will be able to handle this.

[Bug middle-end/23868] [4.9/5/6 regression] builtin_apply uses wrong mode for multi-hard-register return values

[kkojima at gcc dot gnu.org]

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

--- Comment #29 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #28)
> Can anybody comment on the state of this problem here?  Were the two commits
> in comment #2 and comment #3 merged into mainline at some point?

AFAIK, those patches weren't merged.  I guess that other changes for
apply/return buitins fix the failure, though I'm not sure if the original
issue went away completely.

[Bug rtl-optimization/29854] reload_combine looses track of uses

[kkojima at gcc dot gnu.org]

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

--- Comment #7 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #6)
> Looking at the current code in postreload.c, it seems that the patch somehow
> made it into mainline at some point.  Although some of the lines now look a
> bit different.  Can we close this PR as "works for me"?

That sounds reasonable.

[Bug rtl-optimization/70089] ARM/THUMB unnecessarily typecasts some rvalues on memory store

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-06
 CC||segher at gcc dot gnu.org
  Component|c   |rtl-optimization
 Ever confirmed|0   |1

--- Comment #5 from Segher Boessenkool  ---
Confirmed.  Also happens on trunk.  Other targets (e.g. rs6000) have
similar results.  Using things like "x | 0x34100" give even less
pleasant results.

Re: [PATCH, i386]: Fix PR 70024, wrong code with -fPIC and -mred-zone on i686

[H.J. Lu]

On Sun, Mar 6, 2016 at 1:39 PM, Uros Bizjak  wrote:
> Hello!
>
> Attached patch prevents red-zone with -fPIC for leaf functions on
> i686. The idea is to mark when set_got is expanded as a call to a pc
> thunk, and use this flag to prevent red-zone in the current function.
>
> Please note that using red-zone with i686 violates all known ABIs, but
> some future ABI can trip on this limitation. The failure mode is quite
> tricky, so IMO it warrants a couple of lines as a safety net.
>
> The testcase is not suitable for the testsuite (it uses -mred-zone for
> i686 target), but I have checked that the testcase works OK when
> compiled with the patched compiler even when -mred-zone is used
> together with -fPIC.
>
> Jakub, HJ -  what do you think?
>
> 2016-03-01  Uros Bizjak  
>
> PR target/70064
> * config/i386/i386.h (machine_function): Add
> pc_thunk_call_expanded flag.
> (ix86_pc_thunk_call_expanded): New define.
> * config/i386/i386.md (set_got, set_got_labelled): New expanders.
> (*set_got): Rename insn pattern from set_got.
> (*set_got_labelled): Rename inst pattern from set_got_labelled.
> * config/i386/i386.c (ix86_compute_frame_layout): Use
> ix86_pc_thunk_call_expanded to prevent red-zone.
>
> The patch is bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>

I think red zone should only be allowed for x86-64 psABI.


-- 
H.J.

[Bug c++/70106] [4.9/5.3/6.0][C++11 or above] adding parenthesis [cerr << (var)] cause error: invalid static_cast from type 'const size_t {aka const long unsigned int}' to type 'size_t& {aka long unsi

[ppalka at gcc dot gnu.org]

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

--- Comment #2 from Patrick Palka  ---
Oops, wrong reduction.  struct A has to be a template.


template 
struct A
{
  int x;

  void foo () const {
(A::x);
  };
};

void
foo ()
{
  A ().foo ();
}

[Bug c++/70106] [4.9/5.3/6.0][C++11 or above] adding parenthesis [cerr << (var)] cause error: invalid static_cast from type 'const size_t {aka const long unsigned int}' to type 'size_t& {aka long unsi

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Hmm, I can't reproduce the error with -std=c++11, only -std=c++14.

Reduced test case:

struct A
{
  int x;

  void foo () const {
(A::x);
  };
};

void
foo ()
{
  A ().foo ();
}

gcc-6-20160306 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 234014

You'll find:

 gcc-6-20160306.tar.bz2   Complete GCC

  MD5=9f1315f17da582cc38d0d02350868298
  SHA1=ebba862b1f020f54c734b4fae988686f0a6a5308

Diffs from 6-20160228 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
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 target/70110] [6 Regression] ICE at -O3 in the 32-bit mode in set_last_insn, at emit-rtl.h:420

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-06
  Component|rtl-optimization|target
 CC||ienkovich at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE at -O3 in the 32-bit|[6 Regression] ICE at -O3
   |mode in set_last_insn, at   |in the 32-bit mode in
   |emit-rtl.h:420  |set_last_insn, at
   ||emit-rtl.h:420
   Target Milestone|--- |6.0

--- Comment #1 from Uroš Bizjak  ---
Confirmed, a TARGET_STV problem. -O3 -msse2 flags are needed.

(gdb) bt
#0  internal_error (gmsgid=0x1f308b7 "in %s, at %s:%d") at
/home/uros/gcc-svn/trunk/gcc/diagnostic.c:1256
#1  0x018241b0 in fancy_abort (file=0x1913f78
"/home/uros/gcc-svn/trunk/gcc/emit-rtl.h", line=420, 
function=0x1915290 <_ZZL13set_last_insnP8rtx_insnE12__FUNCTION__>
"set_last_insn") at /home/uros/gcc-svn/trunk/gcc/diagnostic.c:1329
#2  0x009a18d0 in set_last_insn (insn=0x7fffef9d2a00) at
/home/uros/gcc-svn/trunk/gcc/emit-rtl.h:420
#3  0x009ac4b1 in end_sequence () at
/home/uros/gcc-svn/trunk/gcc/emit-rtl.c:5442
#4  0x0119806a in scalar_chain::make_vector_copies
(this=0x7fffd8f0, regno=96) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:3276
#5  0x01198c96 in scalar_chain::convert (this=0x7fffd8f0) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:3512
#6  0x01198f47 in convert_scalars_to_vector () at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:3577
#7  0x01199159 in (anonymous namespace)::pass_stv::execute
(this=0x2570ff0) at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:3669
#8  0x00ce0362 in execute_one_pass (pass=0x2570ff0) at
/home/uros/gcc-svn/trunk/gcc/passes.c:2336
#9  0x00ce066a in execute_pass_list_1 (pass=0x2570ff0) at
/home/uros/gcc-svn/trunk/gcc/passes.c:2410
#10 0x00ce069b in execute_pass_list_1 (pass=0x2560740) at
/home/uros/gcc-svn/trunk/gcc/passes.c:2411
#11 0x00ce06f3 in execute_pass_list (fn=0x7fffef970930, pass=0x255d1a0)
at /home/uros/gcc-svn/trunk/gcc/passes.c:2421
#12 0x008f06be in cgraph_node::expand (this=0x7fffef9962e0) at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:1980
#13 0x008f0cf4 in expand_all_functions () at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2116
#14 0x008f180d in symbol_table::compile (this=0x7fffef8730a8) at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2472
#15 0x008f1a3e in symbol_table::finalize_compilation_unit
(this=0x7fffef8730a8) at /home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2562
#16 0x00df3bc3 in compile_file () at
/home/uros/gcc-svn/trunk/gcc/toplev.c:490
#17 0x00df60e3 in do_compile () at
/home/uros/gcc-svn/trunk/gcc/toplev.c:1988
#18 0x00df6368 in toplev::main (this=0x7fffdba0, argc=5,
argv=0x7fffdca8) at /home/uros/gcc-svn/trunk/gcc/toplev.c:2096
#19 0x0180b0e8 in main (argc=5, argv=0x7fffdca8) at
/home/uros/gcc-svn/trunk/gcc/main.c:39
(gdb) f 2
#2  0x009a18d0 in set_last_insn (insn=0x7fffef9d2a00) at
/home/uros/gcc-svn/trunk/gcc/emit-rtl.h:420
420   gcc_checking_assert (!insn || !NEXT_INSN (insn));
(gdb) list
415 /* Specify a new insn as the last in the chain.  */
416
417 static inline void
418 set_last_insn (rtx_insn *insn)
419 {
420   gcc_checking_assert (!insn || !NEXT_INSN (insn));
421   get_current_sequence ()->last = insn;
422 }
423
424 /* Return a number larger than any instruction's uid in this function. 
*/
(gdb) p debug_rtx (insn)
(insn 69 68 145 11 (parallel [
(set (reg:DI 96 [ prephitmp_27 ])
(sign_extend:DI (reg:SI 104 [ c ])))
(clobber (reg:CC 17 flags))
(clobber (scratch:SI))
]) 146 {extendsidi2_1}
 (expr_list:REG_DEAD (reg:SI 104 [ c ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
$1 = void
(gdb) p debug_rtx (NEXT_INSN(insn))
(insn 145 69 146 11 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0  S4 A64])
(subreg:SI (reg:DI 96 [ prephitmp_27 ]) 0)) -1
 (nil))
$2 = void

CC'd author.

[Bug c++/70111] New: Internal compiler error on constant enum access

[tomasz at tomaszklak dot pl]

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

Bug ID: 70111
   Summary: Internal compiler error on constant enum access
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomasz at tomaszklak dot pl
  Target Milestone: ---

Created attachment 37881
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37881=edit
example

The following code fails to compile with "internal compiler error: Segmentation
fault (program cc1plus)" with command "g++ -std=c++11 -Wall -Wextra -pedantic
-ftemplate-depth=10 gccbug.cc"

struct Zero { enum { value = 0 }; };

template 
struct Next { enum { value = 1 + Nat::value }; };

using One   = Next;
using Two   = Next;
using Three = Next;

template 
struct Add;

template 
struct Add
{
using type = Rhs;
};

template 
struct Add
{
using type = Next::type>;
};

using Five = typename Add::type;
using Six = typename Add::type;
using v12 = typename Add::type;
using v18 = typename Add::type;
using v23 = typename Add::type;
using v24 = typename Add::type;

template 
struct Fib;

template<>
struct Fib { using type = One; };

template<>
struct Fib { using type = One; };

template
struct Fib> {
using type = typename Add<
typename Fib::type,
typename Fib::type>::type;
};

int main() {
// This compiles:
// using fib = typename Fib::type;
using fib = typename Fib::type;
(void) fib::value;
}

replacing fib assigment to Fib works fine. Similar behaviour is seen on
5.3.0 - https://goo.gl/rD2zy1

[PATCH, i386]: Fix PR 70024, wrong code with -fPIC and -mred-zone on i686

[Uros Bizjak]

Hello!

Attached patch prevents red-zone with -fPIC for leaf functions on
i686. The idea is to mark when set_got is expanded as a call to a pc
thunk, and use this flag to prevent red-zone in the current function.

Please note that using red-zone with i686 violates all known ABIs, but
some future ABI can trip on this limitation. The failure mode is quite
tricky, so IMO it warrants a couple of lines as a safety net.

The testcase is not suitable for the testsuite (it uses -mred-zone for
i686 target), but I have checked that the testcase works OK when
compiled with the patched compiler even when -mred-zone is used
together with -fPIC.

Jakub, HJ -  what do you think?

2016-03-01  Uros Bizjak  

PR target/70064
* config/i386/i386.h (machine_function): Add
pc_thunk_call_expanded flag.
(ix86_pc_thunk_call_expanded): New define.
* config/i386/i386.md (set_got, set_got_labelled): New expanders.
(*set_got): Rename insn pattern from set_got.
(*set_got_labelled): Rename inst pattern from set_got_labelled.
* config/i386/i386.c (ix86_compute_frame_layout): Use
ix86_pc_thunk_call_expanded to prevent red-zone.

The patch is bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Uros.
Index: i386.c
===
--- i386.c  (revision 234014)
+++ i386.c  (working copy)
@@ -11524,6 +11524,7 @@ ix86_compute_frame_layout (struct ix86_frame *fram
   if (ix86_using_red_zone ()
   && crtl->sp_is_unchanging
   && crtl->is_leaf
+  && !ix86_pc_thunk_call_expanded
   && !ix86_current_function_calls_tls_descriptor)
 {
   frame->red_zone_size = to_allocate;
Index: i386.h
===
--- i386.h  (revision 234014)
+++ i386.h  (working copy)
@@ -2494,6 +2494,10 @@ struct GTY(()) machine_function {
  expander to determine the style used.  */
   BOOL_BITFIELD use_fast_prologue_epilogue : 1;
 
+  /* Nonzero if the current function calls pc thunk and
+ must not use the red zone.  */
+  BOOL_BITFIELD pc_thunk_call_expanded : 1;
+
   /* If true, the current function needs the default PIC register, not
  an alternate register (on x86) and must not use the red zone (on
  x86_64), even if it's a leaf function.  We don't want the
@@ -2533,6 +2537,7 @@ struct GTY(()) machine_function {
 #define ix86_varargs_fpr_size (cfun->machine->varargs_fpr_size)
 #define ix86_optimize_mode_switching (cfun->machine->optimize_mode_switching)
 #define ix86_current_function_needs_cld (cfun->machine->needs_cld)
+#define ix86_pc_thunk_call_expanded (cfun->machine->pc_thunk_call_expanded)
 #define ix86_tls_descriptor_calls_expanded_in_cfun \
   (cfun->machine->tls_descriptor_call_expanded_p)
 /* Since tls_descriptor_call_expanded is not cleared, even if all TLS
Index: i386.md
===
--- i386.md (revision 234014)
+++ i386.md (working copy)
@@ -12470,7 +12470,18 @@
   ""
   "ix86_expand_prologue (); DONE;")
 
-(define_insn "set_got"
+(define_expand "set_got"
+  [(parallel
+ [(set (match_operand:SI 0 "register_operand" "=r")
+  (unspec:SI [(const_int 0)] UNSPEC_SET_GOT))
+  (clobber (reg:CC FLAGS_REG))])]
+  "!TARGET_64BIT"
+{
+  if (flag_pic && !TARGET_VXWORKS_RTP)
+ix86_pc_thunk_call_expanded = true;
+})
+
+(define_insn "*set_got"
   [(set (match_operand:SI 0 "register_operand" "=r")
(unspec:SI [(const_int 0)] UNSPEC_SET_GOT))
(clobber (reg:CC FLAGS_REG))]
@@ -12479,7 +12490,19 @@
   [(set_attr "type" "multi")
(set_attr "length" "12")])
 
-(define_insn "set_got_labelled"
+(define_expand "set_got_labelled"
+  [(parallel
+ [(set (match_operand:SI 0 "register_operand" "=r")
+  (unspec:SI [(label_ref (match_operand 1))]
+ UNSPEC_SET_GOT))
+  (clobber (reg:CC FLAGS_REG))])]
+  "!TARGET_64BIT"
+{
+  if (flag_pic && !TARGET_VXWORKS_RTP)
+ix86_pc_thunk_call_expanded = true;
+})
+
+(define_insn "*set_got_labelled"
   [(set (match_operand:SI 0 "register_operand" "=r")
(unspec:SI [(label_ref (match_operand 1))]
 UNSPEC_SET_GOT))

[Bug rtl-optimization/70110] New: ICE at -O3 in the 32-bit mode in set_last_insn, at emit-rtl.h:420

[su at cs dot ucdavis.edu]

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

Bug ID: 70110
   Summary: ICE at -O3 in the 32-bit mode in set_last_insn, at
emit-rtl.h:420
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu at -O3 in the 32-bit mode (but not in 64-bit mode). 

This is a regression from 5.3.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160306 (experimental) [trunk revision 234012] (GCC) 
$ 
$ gcc-trunk -m32 -O2 -c small.c
$ gcc-trunk -m64 -O3 -c small.c
$ gcc-5.3 -m32 -O3 -c small.c
$ 
$ gcc-trunk -m32 -O3 -c small.c
small.c: In function ‘fn3’:
small.c:36:1: internal compiler error: in set_last_insn, at emit-rtl.h:420
 }
 ^
0x5b4c2d set_last_insn
../../gcc-source-trunk/gcc/emit-rtl.h:420
0x81a309 set_last_insn
../../gcc-source-trunk/gcc/rtl.h:844
0x81a309 end_sequence()
../../gcc-source-trunk/gcc/emit-rtl.c:5442
0xeb451a scalar_chain::make_vector_copies(unsigned int)
../../gcc-source-trunk/gcc/config/i386/i386.c:3276
0xeb5009 scalar_chain::convert()
../../gcc-source-trunk/gcc/config/i386/i386.c:3512
0xeb58b4 convert_scalars_to_vector
../../gcc-source-trunk/gcc/config/i386/i386.c:3577
0xeb58b4 execute
../../gcc-source-trunk/gcc/config/i386/i386.c:3669
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 
$ cat small.c
int a, c, d, f, h;
long long b;

int
fn1 ()
{
  if (a) 
fn1 ();
  b = c;
  return 0;
}

void 
fn2 (int p)
{
  if (p)
f = 0; 
  b |= c; 
} 

void
fn3 ()
{
  b = d;
  for (; (d = 1);)
{
  int g, i;
  a && fn1 ();
  b |= c;
  fn2 (h); 
  fn2 (g); 
  fn2 (h); 
  fn2 (i); 
  fn2 (h);
}
}

int
main ()
{
  return 0; 
}

[Bug tree-optimization/70109] New: [6 Regression] FAIL: gcc.dg/vect/O3-pr36098.c scan-tree-dump-times vect "vectorizing stmts usin g SLP" 0

[hjl.tools at gmail dot com]

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

Bug ID: 70109
   Summary: [6 Regression] FAIL: gcc.dg/vect/O3-pr36098.c
scan-tree-dump-times vect "vectorizing stmts usin g
SLP" 0
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On ia32, r230993 caused:

FAIL: gcc.dg/vect/O3-pr36098.c scan-tree-dump-times vect "vectorizing stmts
usin
g SLP" 0

with -target_board='unix{-m32\ -march=corei7}'"

[Bug libfortran/69799] FAIL: gfortran.dg/coarray_allocate_3.f08 at -O1 and above

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
The patch fixes coarray_allocate_3.f08 but the new testcase fails:

spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc
/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.
11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray_allocate_5
.f08 -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fcoarray=lib
-lcaf_single -fdump-tree-original
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./li
bgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gc
c/objdir/hppa2.0w-hp-hpux11.11/./libatomic/.libs
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/.
/libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -lm -o
./coarray_allocate_5.exe
/usr/ccs/bin/ld: Unsatisfied symbols:   __atomic_fetch_and_4 (first referenced
in /test/gnu/gcc/objdir/hppa2.0w-hp-hp
ux11.11/./libgfortran/.libs/libcaf_single.a(single.o)) (code)
   __atomic_compare_exchange_4 (first referenced in
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o))
(code)   __atomic_fetch_xor_4 (first referenced in
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o))
(code)   __atomic_fetch_add_4 (first referenced in
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o))
(code)   __atomic_fetch_or_4 (first referenced in
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o))
(code)

Needs to link against -latomic.

[Patch, fortran] PRs 70031 and 69524 - submodule tweaks

[Paul Richard Thomas]

Dear All,

These are two rather trivial modifications to permit, 'module' to
appear at any position in the list of prefixes in the procedure
declaration and to allow module procedures to appear within a module
contains section. I was rather astonished at this latter since it does
seem to be rather contrary to having an module interface declaration
for the same procedure. However, from the Fortran 2008 standard:

C1247 (R1225) MODULE shall appear only in the function-stmt or
subroutine-stmt of a module subprogram or of a nonabstract interface
body that is declared in the scoping unit of a module or submodule.

Whilst I was about it, I prevented an ICE from occurring following the
error generated by decl.c(copy_prefix), when prefixes in the interface
are repeated in the procedure declaration. I have not included a test
for this, since I am not convinced that repeating the prefixes is
strictly speaking an error. In fact, it would make a lot of sense to
repeat the interface declaration completely in the submodule
declaration. I will investigate further before committing. The fix is
even more trivial than preventing the ICE.

Since the patch is entirely permissive, it will not prevent correct
code from compiling. In this sense, it is safe for stage 4.

Bootstrapped and regtested on FC21/x86_64. OK for trunk?

Best regards

Paul

2016-03-06  Paul Thomas  

PR fortran/70031
* decl.c (gfc_match_prefix): Treat the 'module' prefix in the
same way as the others, rather than fixing it to come last.
(gfc_match_function_decl, gfc_match_subroutine): After errors
in 'copy_prefix', emit them immediately in the case of module
procedures to prevent a later ICE.

PR fortran/69524
* decl.c (gfc_match_submod_proc): Permit 'module procedure'
declarations within the contains section of modules as well as
submodules.
* resolve.c (resolve_fl_procedure): Likewise.
*trans-decl.c (build_function_decl): Change the gcc_assert to
allow all forms of module procedure declarations within module
contains sections.

2016-03-06  Paul Thomas  

PR fortran/70031
* gfortran.dg/submodule_14.f08: New test

PR fortran/69524
* gfortran.dg/submodule_15.f08: New test
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c  (revision 233937)
--- gcc/fortran/decl.c  (working copy)
*** gfc_match_prefix (gfc_typespec *ts)
*** 4606,4611 
--- 4606,4624 
  {
found_prefix = false;
  
+   /* MODULE is a prefix like PURE, ELEMENTAL, etc., having a
+corresponding attribute seems natural and distinguishes these
+procedures from procedure types of PROC_MODULE, which these are
+as well.  */
+   if (gfc_match ("module% ") == MATCH_YES)
+   {
+ if (!gfc_notify_std (GFC_STD_F2008, "MODULE prefix at %C"))
+   goto error;
+ 
+ current_attr.module_procedure = 1;
+ found_prefix = true;
+   }
+ 
if (!seen_type && ts != NULL
  && gfc_match_decl_type_spec (ts, 0) == MATCH_YES
  && gfc_match_space () == MATCH_YES)
*** gfc_match_prefix (gfc_typespec *ts)
*** 4670,4690 
/* At this point, the next item is not a prefix.  */
gcc_assert (gfc_matching_prefix);
  
-   /* MODULE should be the last prefix before FUNCTION or SUBROUTINE.
-  Since this is a prefix like PURE, ELEMENTAL, etc., having a
-  corresponding attribute seems natural and distinguishes these
-  procedures from procedure types of PROC_MODULE, which these are
-  as well.  */
-   if ((gfc_current_state () == COMP_INTERFACE
-|| gfc_current_state () == COMP_CONTAINS)
-   && gfc_match ("module% ") == MATCH_YES)
- {
-   if (!gfc_notify_std (GFC_STD_F2008, "MODULE prefix at %C"))
-   goto error;
-   else
-   current_attr.module_procedure = 1;
- }
- 
gfc_matching_prefix = false;
return MATCH_YES;
  
--- 4683,4688 
*** gfc_match_function_decl (void)
*** 5639,5647 
if (!gfc_add_function (>attr, sym->name, NULL))
goto cleanup;
  
!   if (!gfc_missing_attr (>attr, NULL)
! || !copy_prefix (>attr, >declared_at))
goto cleanup;
  
/* Delay matching the function characteristics until after the
 specification block by signalling kind=-1.  */
--- 5637,5652 
if (!gfc_add_function (>attr, sym->name, NULL))
goto cleanup;
  
!   if (!gfc_missing_attr (>attr, NULL))
!   goto cleanup;
! 
!   if (!copy_prefix (>attr, >declared_at))
!   {
! if(!sym->attr.module_procedure)
goto cleanup;
+ else
+   gfc_error_check ();
+   }
  
/* Delay matching the function characteristics until after the
 specification block by signalling kind=-1.  */
*** gfc_match_function_decl (void)
*** 5666,5671 
--- 

[Bug c++/58646] ICEs initializing VLAs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2013-10-07 00:00:00 |2016-3-6
 CC||msebor at gcc dot gnu.org
  Known to fail||5.3.0, 6.0

--- Comment #3 from Martin Sebor  ---
Still crashes with the top of trunk (6.0) as well as 5.3.

$ cat z.cpp && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -Wall -Wextra
-Wpedantic z.cpp
void bar (int n)
{
  char a [2][n] = { };
}
z.cpp: In function ‘void bar(int)’:
z.cpp:3:15: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
   char a [2][n] = { };
   ^
z.cpp:3:8: warning: unused variable ‘a’ [-Wunused-variable]
   char a [2][n] = { };
^
z.cpp:3:21: internal compiler error: in make_decl_rtl, at varasm.c:1299
   char a [2][n] = { };
 ^
0x1449b13 make_decl_rtl(tree_node*)
/src/gcc/trunk/gcc/varasm.c:1295
0xcd7cb5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc/trunk/gcc/expr.c:9612
0xcd0ead expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/src/gcc/trunk/gcc/expr.c:7962
0xcb8d57 expand_expr
/src/gcc/trunk/gcc/expr.h:256
0xcdfdc2 expr_size(tree_node*)
/src/gcc/trunk/gcc/expr.c:11633
0xcd0b99 expand_constructor
/src/gcc/trunk/gcc/expr.c:7829
0xcd9123 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc/trunk/gcc/expr.c:9879
0xcd0ead expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/src/gcc/trunk/gcc/expr.c:7962
0xcc8175 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/src/gcc/trunk/gcc/expr.c:5406
0xcc8d79 store_expr(tree_node*, rtx_def*, int, bool, bool)
/src/gcc/trunk/gcc/expr.c:5596
0xccd436 store_field
/src/gcc/trunk/gcc/expr.c:6808
0xcc6247 expand_assignment(tree_node*, tree_node*, bool)
/src/gcc/trunk/gcc/expr.c:5021
0xb8120c expand_gimple_stmt_1
/src/gcc/trunk/gcc/cfgexpand.c:3618
0xb815fd expand_gimple_stmt
/src/gcc/trunk/gcc/cfgexpand.c:3714
0xb8870e expand_gimple_basic_block
/src/gcc/trunk/gcc/cfgexpand.c:5720
0xb8a1d7 execute
/src/gcc/trunk/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug testsuite/70108] New: FAIL: gcc.dg/simulate-thread/speculative-store-2.c -O0 -g thread simulation test

[danglin at gcc dot gnu.org]

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

Bug ID: 70108
   Summary: FAIL: gcc.dg/simulate-thread/speculative-store-2.c
-O0 -g  thread simulation test
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  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

This is a new fail on 5.3.1 and 6.0.0.  It was probably introduced by this
change:

2016-03-03  Rainer Orth  

* lib/gcc-gdb-test.exp (gdb-test): Make log message match command.
Invoke gdb with -batch.
* lib/gcc-simulate-thread.exp (simulate-thread): Likewise.

spawn /mnt/gnu/gcc/objdir-test/gcc/xgcc -B/mnt/gnu/gcc/objdir-test/gcc/
/mnt/gnu
/gcc/gcc/gcc/testsuite/gcc.dg/simulate-thread/speculative-store-2.c
-fno-diagnos
tics-show-caret -fdiagnostics-color=never -O0 -g --param
allow-store-data-races=
0 -O2 -lm -o speculative-store-2.exe
PASS: gcc.dg/simulate-thread/speculative-store-2.c   -O0 -g  (test for excess
er
rors)
Spawning: gdb -nx -nw -batch -x
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/simulate-t
hread/simulate-thread.gdb ./speculative-store-2.exe
spawn gdb -nx -nw -batch -x
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/simulate-threa
d/simulate-thread.gdb ./speculative-store-2.exe
Traceback (most recent call last):
  File "/home/gnu/share/gdb/python/gdb/__init__.py", line 108, in
auto_load_pack
ages
__import__(modname)
  File "/home/gnu/share/gdb/python/gdb/command/frame_filters.py", line 22, in

from gdb.FrameIterator import FrameIterator
  File "/home/gnu/share/gdb/python/gdb/FrameIterator.py", line 17, in 
import itertools
ImportError: Failed to load /home/gnu/lib/python2.7/lib-dynload/itertools.sl

Breakpoint 1 at 0x2e40: file
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/simulate-thre
ad/speculative-store-2.c, line 50.
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.

Breakpoint 1, simulate_thread_main () at
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/simulate-thread/speculative-store-2.c:50
50  if (p->data > 0)
warning: Cannot find suitable address to place dummy breakpoint; nested calls
may fail.
0x2e44  50  if (p->data > 0)
warning: Cannot find suitable address to place dummy breakpoint; nested calls
may fail.
warning: Cannot find suitable address to place dummy breakpoint; nested calls
may fail.
0x2e44  50  if (p->data > 0)warning: Cannot find suitable
address to place dummy breakpoint; nested calls ma
y fail.
warning: Cannot find suitable address to place dummy breakpoint; nested calls
may fail.
49for (p = q; p; p = p->next)warning: Cannot find suitable address to
place dummy breakpoint; nested calls ma
y fail.
warning: Cannot find suitable address to place dummy breakpoint; nested calls
may fail.
0x2e54  49for (p = q; p; p = p->next)
warning: Cannot find suitable address to place dummy breakpoint; nested calls
may fail.
warning: Cannot find suitable address to place dummy breakpoint; nested calls
may fail.
0x2e58  49for (p = q; p; p = p->next)
warning: Cannot find suitable address to place dummy breakpoint; nested calls
may fail.
warning: Cannot find suitable address to place dummy breakpoint; nested calls
may fail.
0x2e44  50  if (p->data > 0)
[...]
49for (p = q; p; p = p->next)warning: Cannot find suitable address to
place dummy breakpoint; nested calls may fail.
warning: Cannot find suitable address to place dummy breakpoint; nested calls
may fail.
FAIL: Testcase exceeded maximum instruction count threshold
FAIL: gcc.dg/simulate-thread/speculative-store-2.c   -O0 -g  thread simulation
t
est

Similar fails:

FAIL: gcc.dg/simulate-thread/speculative-store-2.c   -O2 -g  thread simulation
t
est
FAIL: gcc.dg/simulate-thread/speculative-store-2.c   -O3 -g  thread simulation
t
est
FAIL: gcc.dg/simulate-thread/speculative-store-4.c   -O0 -g  thread simulation
t
est

[Bug fortran/70058] Segmentation fault when open file with existing file and status = "UNKNOWN"

[ranftmaps at hotmail dot com]

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

--- Comment #8 from Paul  ---
I downloaded the latest version I could find from
https://sourceforge.net/projects/mingw-w64/?source=typ_redirect.   It is
version 5.3.0.   The problem does not exist with version 5.3.0.  My apologies
for not finding the latest gfortran version earlier.

[PATCH, RFC]. Some initial work on coroutines

[Mikhail Maltsev]

Hi, all!

I decided to start working on coroutines support in C++ (according to P0057R2
proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0057r2.pdf).

I did some analysis of how other compilers implement coroutines:
https://github.com/miyuki-chan/coroutines
This github repo has a small example project for Microsoft Visual Studio and
also the relevant part of assembly code generated by MSVC.
It also has a link to Clang testcase for coroutines semantic analysis and
diagnostics, as well as the actual diagnostic output of Clang for that testcase.

In the attached patch I started to work on parsing and semantic analysis. For
now it can parse some basic uses of co_await, co_yield and co_return and
diagnose some erroneous cases. No support for templates, and no 'for co_await' 
yet.

My main question is: what is the correct way of constructing the AST? I started
looking at how range-based for loops are implemented. As far as I understand,
GCC converts range-based for into normal for loop immediately, when possible,
i.e. when there are no dependent types involved. But when parsing template
definition, GCC may create a node for range-based for loop and convert it during
instantiation. Should we do the same for co_await/co_yield/co_return? Or would
it be better to always construct just AST nodes (perhaps with some
meta-information) and delay actual codegen until we start genericising the
function (apparently, Clang works this way)?

Just it case, what I mean by codegen. The proposal says:
"Let e be the operand of the yield-expression and p be an lvalue naming the
promise object of the enclosing coroutine (8.4.4), then the yield-expression is
equivalent to the expression co_await p.yield_value(e)."
So, when we parse "co_yield e", when should we build "co_await p.yield_value(e)"
from it and further expand co_await?

-- 
Regards,
Mikhail Maltsev
diff --git a/.gitignore b/.gitignore
index c9a6158..4595d5e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,6 +37,9 @@ TAGS.sub
 
 .clang-format
 
+.agignore
+.ycm_extra_conf.py
+
 .gdbinit
 .gdb_history
 
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 22ea7da..9962ab5 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -598,6 +598,11 @@ const struct c_common_resword c_common_reswords[] =
   { "concept",		RID_CONCEPT,	D_CXX_CONCEPTS_FLAGS | D_CXXWARN },
   { "requires", 	RID_REQUIRES,	D_CXX_CONCEPTS_FLAGS | D_CXXWARN },
 
+  /* C++ coroutines */
+  { "co_await",		RID_CO_AWAIT,	D_CXX_COROUTINES_FLAGS | D_CXXWARN },
+  { "co_return", 	RID_CO_RETURN,	D_CXX_COROUTINES_FLAGS | D_CXXWARN },
+  { "co_yield", 	RID_CO_YIELD,	D_CXX_COROUTINES_FLAGS | D_CXXWARN },
+
   /* These Objective-C keywords are recognized only immediately after
  an '@'.  */
   { "compatibility_alias", RID_AT_ALIAS,	D_OBJC },
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index fa3746c..4f753c9 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -154,6 +154,9 @@ enum rid
   /* C++ concepts */
   RID_CONCEPT, RID_REQUIRES,
 
+  /* C++ coroutines */
+  RID_CO_AWAIT, RID_CO_RETURN, RID_CO_YIELD,
+
   /* C++ transactional memory.  */
   RID_ATOMIC_NOEXCEPT, RID_ATOMIC_CANCEL, RID_SYNCHRONIZED,
 
@@ -383,20 +386,22 @@ extern machine_mode c_default_pointer_mode;
mask) is _true_.  Thus for keywords which are present in all
languages the disable field is zero.  */
 
-#define D_CONLY		0x001	/* C only (not in C++).  */
-#define D_CXXONLY	0x002	/* C++ only (not in C).  */
-#define D_C99		0x004	/* In C, C99 only.  */
-#define D_CXX11 0x008	/* In C++, C++11 only.  */
-#define D_EXT		0x010	/* GCC extension.  */
-#define D_EXT89		0x020	/* GCC extension incorporated in C99.  */
-#define D_ASM		0x040	/* Disabled by -fno-asm.  */
-#define D_OBJC		0x080	/* In Objective C and neither C nor C++.  */
-#define D_CXX_OBJC	0x100	/* In Objective C, and C++, but not C.  */
-#define D_CXXWARN	0x200	/* In C warn with -Wcxx-compat.  */
-#define D_CXX_CONCEPTS  0x400   /* In C++, only with concepts. */
-#define D_TRANSMEM	0X800   /* C++ transactional memory TS.  */
+#define D_CONLY		  0x0001  /* C only (not in C++).  */
+#define D_CXXONLY	  0x0002  /* C++ only (not in C).  */
+#define D_C99		  0x0004  /* In C, C99 only.  */
+#define D_CXX11		  0x0008  /* In C++, C++11 only.  */
+#define D_EXT		  0x0010  /* GCC extension.  */
+#define D_EXT89		  0x0020  /* GCC extension incorporated in C99.  */
+#define D_ASM		  0x0040  /* Disabled by -fno-asm.  */
+#define D_OBJC		  0x0080  /* In Objective C and neither C nor C++.  */
+#define D_CXX_OBJC	  0x0100  /* In Objective C, and C++, but not C.  */
+#define D_CXXWARN	  0x0200  /* In C warn with -Wcxx-compat.  */
+#define D_CXX_CONCEPTS	  0x0400  /* In C++, only with concepts. */
+#define D_TRANSMEM	  0x0800  /* C++ transactional memory TS.  */
+#define D_CXX_COROUTINES  0x1000  /* C++ coroutines TS.  */
 
 #define D_CXX_CONCEPTS_FLAGS D_CXXONLY | D_CXX_CONCEPTS
+#define 

[Bug target/70098] PowerPC64: eigen hits ICE in reload

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||vmakarov at gcc dot gnu.org

--- Comment #4 from Segher Boessenkool  ---
No matter what I try, I cannot convince IRA not to use FLOAT_REGS here.
Vladimir, any ideas?

[Bug c/70088] ARM/THUMB unnecessarily typecasts some rvalues on memory store

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Earnshaw  ---
Dup

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

[Bug c/70089] ARM/THUMB unnecessarily typecasts some rvalues on memory store

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
*** Bug 70088 has been marked as a duplicate of this bug. ***

[Bug c/70089] ARM/THUMB unnecessarily typecasts some rvalues on memory store

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Earnshaw  ---
Re-opening.

Re: [gimplefe] [gsoc16] Gimple Front End Project

[Richard Biener]

On March 6, 2016 3:45:37 PM GMT+01:00, Diego Novillo  
wrote:
>On Sun, Mar 6, 2016 at 6:03 AM, Prasad Ghangal
> wrote:
>> Hi!
>>
>> On stackoverflow
>> http://stackoverflow.com/questions/21660563/can-gcc-compile-gimple,
>> they said GIMPLE FE project is dead. Please let me know if I can work
>> on it for gsoc.
>
>I stopped working on GIMPLE FE a long time ago.  Even though I'm no
>longer doing any GCC work, this is still one project I would like to
>see completed.  Unfortunately, I've been away for long enough that I
>would not be an effective mentor for this project.
>
>I'm sure you'll find enough interest in the GCC community.  Several
>folks would be able to mentor you with this.

I'll be willing to mentor this.  Though I'd rather have us starting from 
scratch and look at having a C-like input language, even piggy-backing on the C 
frontend maybe.

Richard.

>
>Diego.

[Bug target/29969] should use floating point registers for block copies

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
(In reply to Oleg Endo from comment #4)
> If this is true, using 64 bit fmov for block moves could be beneficial.
> Still, I'd not enable this by default but allow the user to turn it on
> with an -m option.

Actually, for an FP enabled target the only case where it is counter productive
is interrupt handlers.  If that's the only FP use in the ISR, it will add
register push/pops.  To avoid this, it's better to also have a function
attribute to enable or disable FP mode copies.

[Bug target/70107] ICE: in emit_move_insn, at expr.c:3546 with -mcpu=power8

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
All supported gcc versions ICE.

[Bug target/70107] New: ICE: in emit_move_insn, at expr.c:3546 with -mcpu=power8

[trippels at gcc dot gnu.org]

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

Bug ID: 70107
   Summary: ICE: in emit_move_insn, at expr.c:3546 with
-mcpu=power8
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---
Target: ppc64le

trippels@gcc2-power8 test % cat apply.ii
struct {
  template 
  auto operator()(T Base::*, Derived ref) -> decltype(ref);
} a;
struct TestClass {};
template 
void test_b12(Functor f) {
  using ClassFunc = Signature TestClass::*;
  ClassFunc b;
  a(b, f);
}
void foo() {
  TestClass c;
  test_b12(c);
}

trippels@gcc2-power8 test % /home/trippels/gcc_test/usr/local/bin/g++ -w -c
-mcpu=power8 apply.ii
apply.ii: In function ‘void test_b12(Functor) [with Signature = int();
 = int; Functor = TestClass]’:
apply.ii:10:4: internal compiler error: in emit_move_insn, at expr.c:3546
   a(b, f);
   ~^~
0x106cd757 emit_move_insn(rtx_def*, rtx_def*)
../../gcc/gcc/expr.c:3545
0x10558def load_register_parameters
../../gcc/gcc/calls.c:2047
0x10558def expand_call(tree_node*, rtx_def*, int)
../../gcc/gcc/calls.c:3329
0x106c699f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10594
0x10570907 expand_expr
../../gcc/gcc/expr.h:256
0x10570907 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2660
0x10570907 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3548
0x10570907 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3714
0x10574413 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5720
0x10579887 execute
../../gcc/gcc/cfgexpand.c:6335

[Bug rtl-optimization/29854] reload_combine looses track of uses

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org,
   ||olegendo at gcc dot gnu.org

--- Comment #6 from Oleg Endo  ---
(In reply to Jorn Wolfgang Rennecke from comment #0)
> 
> A patch is here:
> http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01387.html

And the latest feedback for that was this:
https://gcc.gnu.org/ml/gcc-patches/2006-01/msg01473.html


Looking at the current code in postreload.c, it seems that the patch somehow
made it into mainline at some point.  Although some of the lines now look a bit
different.  Can we close this PR as "works for me"?

Re: [gimplefe] [gsoc16] Gimple Front End Project

[Diego Novillo]

On Sun, Mar 6, 2016 at 6:03 AM, Prasad Ghangal  wrote:
> Hi!
>
> On stackoverflow
> http://stackoverflow.com/questions/21660563/can-gcc-compile-gimple,
> they said GIMPLE FE project is dead. Please let me know if I can work
> on it for gsoc.

I stopped working on GIMPLE FE a long time ago.  Even though I'm no
longer doing any GCC work, this is still one project I would like to
see completed.  Unfortunately, I've been away for long enough that I
would not be an effective mentor for this project.

I'm sure you'll find enough interest in the GCC community.  Several
folks would be able to mentor you with this.


Diego.

Re: [PATCH] Fix PR c++/66786 (ICE with nested lambdas in variable template)

[Patrick Palka]

On Sun, Mar 6, 2016 at 1:42 AM, Jason Merrill  wrote:
> On 02/08/2016 12:19 AM, Patrick Palka wrote:
>>
>> Here, we are calling template_class_depth on a FIELD_DECL corresponding
>> to a lambda that is used inside variable template.  template_class_depth
>> however does not see that this FIELD_DECL is used inside a variable
>> template binding because its chain of DECL_CONTEXTs does not include the
>> corresponding VAR_DECL.  So template_class_depth returns the wrong
>> template nesting level which causes its callers to malfunction.  In
>> particular we strip a template argument level in
>> tsubst_copy [FIELD_DECL] when we shouldn't have.
>>
>> This patch makes template_class_depth look at a lambda type's
>> LAMBDA_TYPE_EXTRA_SCOPE field instead of its TYPE_CONTEXT, so that it
>> can iterate into an enclosing variable template, if applicable.
>>
>> Tested on x86_64-pc-linux gnu, no new regressions.  Also tested against
>> Boost.  Is this OK to commit?
>
>
> This is breaking several lambda testcases with -fconcepts on;
> LAMBDA_TYPE_EXTRA_SCOPE can also be a FIELD_DECL or PARM_DECL.  Let's just
> check DECL_P.

Sorry about that.

In the case of LAMBDA_TYPE_EXTRA_SCOPE being a PARM_DECL, could there
be a chance that this PARM_DECL has a non-null DECL_LANG_SPECIFIC? If
so it looks like we could still later ICE in get_template_info (called
from template_class_depth) when we try to get at its
DECL_TEMPLATE_INFO, an accessor that cannot be used on PARM_DECLs.  So
I wonder if maybe get_template_info() should also be adjusted to
handle the case of being given a PARM_DECL which may have a non-null
DECL_LANG_SPECIFIC:

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 823e2f0..f68b1f6 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -330,7 +330,8 @@ get_template_info (const_tree t)
   if (!t || t == error_mark_node)
 return NULL;

-  if (TREE_CODE (t) == NAMESPACE_DECL)
+  if (TREE_CODE (t) == NAMESPACE_DECL
+  || TREE_CODE (t) == PARM_DECL)
 return NULL;

   if (DECL_P (t) && DECL_LANG_SPECIFIC (t))
@@ -378,7 +379,7 @@ template_class_depth (tree type)
  && uses_template_parms (INNERMOST_TEMPLATE_ARGS (TI_ARGS (tinfo
++depth;

-  if (VAR_OR_FUNCTION_DECL_P (type))
+  if (DECL_P (type))
type = CP_DECL_CONTEXT (type);
   else if (LAMBDA_TYPE_P (type))
type = LAMBDA_TYPE_EXTRA_SCOPE (type);

[Bug c++/67185] [C++14] Link error on ODR-use of variable template partial specialization

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
With checking:

temp.ii:9:13: internal compiler error: in get_partitioning_class, at
symtab.c:1794
 int main() {}
 ^
0x90b559 symtab_node::get_partitioning_class()
../../gcc/gcc/symtab.c:1794
0xbab37f lto_output_varpool_node
../../gcc/gcc/lto-cgraph.c:611
0xbab37f output_symtab()
../../gcc/gcc/lto-cgraph.c:1021
0xbbd5ea lto_output()
../../gcc/gcc/lto-streamer-out.c:2381
0xc2c0ae write_lto
../../gcc/gcc/passes.c:2434
0xc2f9de ipa_write_summaries_1
../../gcc/gcc/passes.c:2498
0xc2f9de ipa_write_summaries()
../../gcc/gcc/passes.c:2558
0x921c7f ipa_passes
../../gcc/gcc/cgraphunit.c:2308
0x921c7f symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2402
0x9244d2 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2536
0x9244d2 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2562
Please submit a full bug report,

[Bug c++/67185] [C++14] Link error on ODR-use of variable template partial specialization

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-06
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Markus Trippelsdorf  ---
With -flto we even ICE:

markus@x4 /tmp % g++ -flto temp.ii

temp.ii:9:13: internal compiler error: in write_symbol, at
lto-streamer-out.c:2561

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
Bug 29842 depends on bug 28144, which changed state.

Bug 28144 Summary: floating point constant -> byte/char/short conversion is 
wrong for java
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144

   What|Removed |Added

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

[Bug tree-optimization/27394] double -> char conversion varies with optimization level

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394
Bug 27394 depends on bug 28144, which changed state.

Bug 28144 Summary: floating point constant -> byte/char/short conversion is 
wrong for java
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144

   What|Removed |Added

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

[Bug tree-optimization/28144] floating point constant -> byte/char/short conversion is wrong for java

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #6 from Oleg Endo  ---
Closing as invalid for the same reason as PR 27394.

[Bug c++/67185] [C++14] Link error on ODR-use of variable template partial specialization

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

  Attachment #36170|0   |1
is obsolete||

--- Comment #2 from Casey Carter  ---
Created attachment 37880
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37880=edit
Minimal non-concepts (C++14) test case

Announce: GNU MPFR 3.1.4 is released

[Vincent Lefevre]

GNU MPFR 3.1.4 ("canard à l'orange", patch level 4), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  http://www.mpfr.org/mpfr-3.1.4/

from InriaForge:

  https://gforge.inria.fr/projects/mpfr/

and from the GNU FTP site:

  http://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The SHA1 digests:
e3b0af77f18505184410d621fe0aae179e229dba  mpfr-3.1.4.tar.bz2
272212c889d0ad6775ab6f315d668f3d01d1eaa3  mpfr-3.1.4.tar.gz
cedc0055d55b6ee4cd17e1e6119ed412520ff81a  mpfr-3.1.4.tar.xz
8bad43f51fd9f4710e79fa7a274ccae7ca72a38c  mpfr-3.1.4.zip

The SHA256 digests:
d3103a80cdad2407ed581f3618c4bed04e0c92d1cf771a65ead662cc397f7775  
mpfr-3.1.4.tar.bz2
0d4de7e1476f79d24c38d5bc04a06fcc9a1bb9cf35fd654ceada29af03ad1844  
mpfr-3.1.4.tar.gz
761413b16d749c53e2bfd2b1dfaa3b027b0e793e404b90b5fbaeef60af6517f5  
mpfr-3.1.4.tar.xz
81285def6be6d7aae6dba1944e5fad3f016752fc6a7ceede8a6f2a22fc36f1dd  mpfr-3.1.4.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified
using the DSA key ID 98C3739D; this key can be retrieved with:

  gpg --recv-keys 98C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 3.1.3 to version 3.1.4:
- Improved MPFR manual.
- Bug fixes (see  and ChangeLog file).
- MinGW (MS Windows): Added support for thread-safe DLL (shared library).

You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 3.1.4 web page.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Bug c++/67210] [concepts] Error parsing ">>" after a template-id that names a concept

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

  Attachment #36183|0   |1
is obsolete||
 CC||Casey at Carter dot net

--- Comment #1 from Casey Carter  ---
Created attachment 37879
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37879=edit
Minimal non-concepts (C++14) test case

Re: [gimplefe] [gsoc16] Gimple Front End Project

[Trevor Saunders]

On Sun, Mar 06, 2016 at 04:33:30PM +0530, Prasad Ghangal wrote:
> Hi!
> 
> On stackoverflow
> http://stackoverflow.com/questions/21660563/can-gcc-compile-gimple,
> they said GIMPLE FE project is dead. Please let me know if I can work
> on it for gsoc.

Well, nobody has worked on it for a long time, but I think there's a
number of people who'd like to see something like that get finished.  I
don't know that I'm capable of mentoring this on my own, but I'd be
willing to help out, and istr David malcolm was talking about working on
the gimple fe for gcc 7.

Trev

> 
> On 5 March 2016 at 03:01, Prasad Ghangal  wrote:
> > Hi!
> >
> > I am interested to work on Gimple FE project for gsoc16. I would like
> > to know the scope of the project for gsoc. Also anyone like to mentor
> > me for the project?
> >
> >
> >
> >
> > Thanks and Regards,
> > Prasad Ghangal
> 
> 
> 
> -- 
> Thanks and Regards,
> Prasad Ghangal

[Bug c++/67185] [C++14] Link error on ODR-use of variable template partial specialization

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net
Version|6.0 |5.3.0
 Blocks|67491   |
Summary|[concepts] Link error on|[C++14] Link error on
   |ODR-use of constexpr|ODR-use of variable
   |constrained variable|template partial
   |template partial|specialization
   |specialization  |

--- Comment #1 from Casey Carter  ---
This same bug is triggered by the purely C++14 program:

template 
bool x = false;

template 
bool x = true;

bool& f() { return x; }

int main() {}

which when compiled with either g++ 5.3 or 6 results in 

/tmp/ccHHu1ip.o: In function `f()':
prog.cc:(.text+0x5): undefined reference to `x'
collect2: error: ld returned 1 exit status

The problem has nothing to do with concepts or constexpr, but seems to be a
general issue when ODR-using an instance of a template variable that was
instantiated from a partial specialization. I'm recasting this as a C++14 bug
against 5.3.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[PATCH][ARM,testsuite] fix pragma_cpp_fma testcase

[Christophe Lyon]

Hi,

In commit r233654, Christian introduced a new test: pragma_cpp_fma.

Unfortunately, this test fails when gcc is configured --with-fpu >=
neonvfpv4: __ARM_FEATURE_FMA is still defined after the last
pop_options.

To address this, I propose to simply force fpu=vfp via a pragma at the
beginning of the test, like we do in several other similar tests.

OK?

Christophe.
2016-03-07  Christophe Lyon  

* gcc.target/arm/pragma_cpp_fma.c: Reset default FPU.
diff --git a/gcc/testsuite/gcc.target/arm/pragma_cpp_fma.c 
b/gcc/testsuite/gcc.target/arm/pragma_cpp_fma.c
index be63256..c72ea8c 100644
--- a/gcc/testsuite/gcc.target/arm/pragma_cpp_fma.c
+++ b/gcc/testsuite/gcc.target/arm/pragma_cpp_fma.c
@@ -4,6 +4,9 @@
 /* { dg-require-effective-target arm_fp_ok } */
 /* { dg-add-options arm_fp } */
 
+/* Reset fpu to a value compatible with the next pragmas.  */
+#pragma GCC target ("fpu=vfp")
+
 #pragma GCC push_options
 #pragma GCC target ("fpu=crypto-neon-fp-armv8")
 

[Bug tree-optimization/27394] double -> char conversion varies with optimization level

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||olegendo at gcc dot gnu.org
 Resolution|--- |INVALID
  Known to fail||

--- Comment #9 from Oleg Endo  ---
I've briefly checked this issue on trunk / sh-elf.
For -O0 function 'f' returns -128, while -O1 returs 127.  At -O1 'f' gets
inlined and main returns '1'.

Anyway, I think this can be closed.  The test case is showing that undefined
behavior is undefined while the main motivation seems to be debugging.  For
that there are more modern debugging tools available these days.  For example
the option -fsanitize=float-cast-overflow will catch this problem.

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
Bug 29842 depends on bug 27394, which changed state.

Bug 27394 Summary: double -> char conversion varies with optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394

   What|Removed |Added

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

[Bug tree-optimization/67628] [tree-optimization] (a && b) && c shows better codegen than a && (b && c)

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
*** Bug 70087 has been marked as a duplicate of this bug. ***

[Bug middle-end/70087] Different (worse?) code generated for "if (a || (b || c))" vs "if (a || b || c)"

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Patrick Palka  ---
Tagged as a duplicate

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

[Bug debug/24801] -d option changes debug information

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #3 from Oleg Endo  ---
(In reply to Jorn Wolfgang Rennecke from comment #1)
> 
> For sh-elf,
> ./cc1 -fpreprocessed -g -O2  l0.c -o l0.s-0
> ./cc1 -fpreprocessed -g -O2  l0.c -o l0.s-01
> ./cc1 -fpreprocessed -g -O2  l0.c -o l0.s-02
> all produce the same result (with address space randomization active),
> which is differs in debug info from what you get with any of:
> ./cc1 -fpreprocessed -g -O2  l0.c -o l0.s-1  -da
> ./cc1 -fpreprocessed -g -O2  l0.c -o l0.s-11  -da
> ./cc1 -fpreprocessed -g -O2  l0.c -o l0.s-12  -da

(In reply to Richard Biener from comment #2)
> Still?

I have checked the test case on sh-elf with the above flags.  The resulting
files are identical.  I guess we can close this PR.  Not sure how to add the
test case to the test suite though.

[Bug c++/70106] New: [4.9/5.3/6.0][C++11 or above] adding parenthesis [cerr << (var)] cause error: invalid static_cast from type 'const size_t {aka const long unsigned int}' to type 'size_t& {aka long

[david.abdurachmanov at gmail dot com]

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

Bug ID: 70106
   Summary: [4.9/5.3/6.0][C++11 or above] adding parenthesis [cerr
<< (var)] cause error: invalid static_cast from type
'const size_t {aka const long unsigned int}' to type
'size_t& {aka long unsigned int&}'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com
  Target Milestone: ---

Created attachment 37878
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37878=edit
test case

I came across this while recompiling our repositories with GCC 6.0.0 (r233941,
a couple of days old already). Only happens with C++11 or above. Seems to
affect GCC 4.9.3, 5.3.0, and GCC 6.0.0. Works fine with Clang 3.7.0 and the
latest version of ICC (16.0.2 20160204).

I did run C-Reduce and then did some additional manual minimisation.

Test case attached.

### COMPILING ###

g++ -std=c++14 -Wno-deprecated -c ratext_worker_min_new.cpp -fPIC  -o
ratext_worker.o

### ERROR ###

ratext_worker_min_new.cpp: In instantiation of ‘const int&
momentum_configuration<  >::p(size_t) const [with
 = int; size_t = long unsigned int]’:
ratext_worker_min_new.cpp:22:25:   required from ‘void momentum_configuration<
 >::mom(size_t) [with  = int;
size_t = long unsigned int]’
ratext_worker_min_new.cpp:53:3:   required from ‘void triangle_Rat_plusminus<
,
RatTriSpecs>::get_sub_terms_work(momentum_configuration&, const
std::vector&, triangle_param&) [with T = int;  = rat_worker; RatTriSpecs =
Higgs_RatTri_Specification]’
ratext_worker_min_new.cpp:58:50:   required from here
ratext_worker_min_new.cpp:28:13: error: invalid static_cast from type ‘const
size_t {aka const long unsigned int}’ to type ‘size_t& {aka long unsigned
int&}’
   std::cerr << (momentum_configuration::nbr);
 ^

### EXPECTATIONS ###

The issue is this line:

 28   std::cerr << (momentum_configuration::nbr);

Removing parenthesis resolves the issue:

 28   std::cerr << momentum_configuration::nbr;

Clang and ICC compile the code in C++14 with and without the parenthesis.

[Bug middle-end/23868] [4.9/5/6 regression] builtin_apply uses wrong mode for multi-hard-register return values

[olegendo at gcc dot gnu.org]

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

--- Comment #28 from Oleg Endo  ---
I've just briefly checked gcc/testsuite/gcc.dg/builtin-apply4.c on sh-elf after
removing the following conditions:

Index: gcc/testsuite/gcc.dg/builtin-apply4.c
===
--- gcc/testsuite/gcc.dg/builtin-apply4.c   (revision 234013)
+++ gcc/testsuite/gcc.dg/builtin-apply4.c   (working copy)
@@ -1,8 +1,6 @@
 /* PR tree-optimization/20076 */
 /* { dg-options "-O2 -Wmissing-noreturn -fgnu89-inline" } */
-/* { dg-additional-options "-mno-mmx" { target { { i?86-*-* x86_64-*-* } &&
ia32 } } } */
 /* { dg-do run } */
-/* { dg-require-effective-target untyped_assembly } */

 extern void abort (void);


It seems the test passes on sh-elf.

Can anybody comment on the state of this problem here?  Were the two commits in
comment #2 and comment #3 merged into mainline at some point?

[Bug middle-end/70100] [5 Regression] ICE: in execute, at cfgexpand.c:6066

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.0
   Last reconfirmed||2016-03-06
  Component|c++ |middle-end
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|internal compiler error: in |[5 Regression] ICE: in
   |execute, at |execute, at
   |cfgexpand.c:6066|cfgexpand.c:6066
   Severity|major   |normal

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 /tmp % cat main.ii
namespace std {
template  struct integral_constant {
  static constexpr _Tp value = 0;
};
template  _Tp declval;
template 
struct is_same : integral_constant {};
template  struct A { typedef _Tp type; };
template  struct A<_Tp &> { typedef _Tp type; };
template  struct B { typedef typename A<_Tp>::type type; };
template  struct enable_if;
template  struct C;
template  struct D {};
template > struct F;
}
template  using Decay = typename std::B::type;
namespace std {
struct G {
  G(int);
};
}
template  struct Gen {
  template ::value>>
  Gen(Impl &&);
  struct H;
  template  struct L;
  H *m_impl;
};
template  struct Gen::H {};
template  template  struct Gen::L : H {
  template  L(Args... args) : m_impl(args...), m_count(0) {
m_impl(0, 0);
  }
  Impl m_impl;
  std::G m_count;
};
template 
template 
Gen::Gen(Impl &) : m_impl(new L(impl)) {}
namespace state {
template  struct Command {
  using Model = int;
  using CommandType = Command;
};
template  using Commands = std::F;
template )>
void check(MakeInitialState &&, Sut &, GenFunc &&);
namespace gen {
template ::value>>
Gen commands(MakeInitialState &&, GenerationFunc &&);
template  struct I {
  template 
  I(InitialStateArg, GenFuncArg);
  void operator()(int, int) { J(0, 0, m_genFunc, 0); }
  struct J {
J(int, int, GenFunc, int) { m_genFunc(0); }
GenFunc m_genFunc;
  };
  GenFunc m_genFunc;
};
template 
Gen commands(MakeInitialState &&, GenerationFunc &&) {
  return I(0, 0);
}
}
template 
void check(MakeInitialState &&, Sut &, GenFunc &) {
  using Model = Decay;
  gen::commands>(0, generationFunc);
}
namespace gen {
template  struct K {
  using CmdSP = std::D;
  template  void operator()(Args... args) {
using MakeFunc = CmdSP(...);
MakeFunc makeFuncs;
[=] { [=] { makeFuncs(args...); }; };
  }
};
template  K execOneOfWithArgs();
}
}
using DbCommand = state::Command;
struct Get : DbCommand {};
int main() {
  void db();
  check(0, db, state::gen::execOneOfWithArgs());
}

markus@x4 /tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/5.3.1/g++ -std=c++14 -c
main.ii
main.ii: In member function ‘void state::gen::K::operator()(Args ...)
[with Args = {int}; Cmd = Get]’:
main.ii:79:36: internal compiler error: in execute, at cfgexpand.c:6069

Might be related to PR68798.

[Bug c++/70105] [6 regression] giant warning when building gcc-5 with gcc-6

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

Re: [gimplefe] [gsoc16] Gimple Front End Project

[Prasad Ghangal]

Hi!

On stackoverflow
http://stackoverflow.com/questions/21660563/can-gcc-compile-gimple,
they said GIMPLE FE project is dead. Please let me know if I can work
on it for gsoc.

On 5 March 2016 at 03:01, Prasad Ghangal  wrote:
> Hi!
>
> I am interested to work on Gimple FE project for gsoc16. I would like
> to know the scope of the project for gsoc. Also anyone like to mentor
> me for the project?
>
>
>
>
> Thanks and Regards,
> Prasad Ghangal



-- 
Thanks and Regards,
Prasad Ghangal

[Bug c/70104] Should give an error when using multiple case value in switch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
'a' || 'A' is 1, so there is no reason to give an error about it.
The error in the second case is because you have two case labels with the same
value, 1.  That is not allowed in a switch.

[Bug c++/70105] New: [6 regression] giant warning when building gcc-5 with gcc-6

[trippels at gcc dot gnu.org]

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

Bug ID: 70105
   Summary: [6 regression] giant warning when building gcc-5 with
gcc-6
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

markus@x4 gcc % g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I.
-I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/gcc/../libbacktrace -o tree-complex.o -MT tree-complex.o -MMD -MP
-MF ./.deps/tree-complex.TPo ../../gcc/gcc/tree-complex.c

In file included from ./tm.h:27:0,
 from ../../gcc/gcc/tree-complex.c:23:
../../gcc/gcc/config/elfos.h:102:21: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\
 ^
../../gcc/gcc/config/elfos.h:170:24: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
   fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n",  \
^
In file included from ./tm.h:48:0,
 from ../../gcc/gcc/tree-complex.c:23:
../../gcc/gcc/defaults.h:126:24: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
   fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n",  \
^
In file included from ../../gcc/gcc/tree-complex.c:57:0:
../../gcc/gcc/tree-complex.c: In function ‘tree_node*
create_one_component_var(tree, tree, const char*, const char*, tree_code)’:
../../gcc/gcc/../include/libiberty.h:184:25: warning: operation on
‘libiberty_concat_ptr’ may be undefined [-Wsequence-point]
   (libiberty_concat_ptr = (char *) alloca (concat_length ACONCAT_PARAMS + 1),
\
   
~^~~
concat_copy2 ACONCAT_PARAMS)



 /* Check whether two file descriptors refer to the same file.  */
 ~


 extern int fdmatch (int fd1, int fd2);
 ~~


 /* Return the position of the first bit set in the argument.  */
 
 /* Prototypes vary from system to system, so we only provide a
 ~~
prototype on systems where we know that we need it.  */
~~~
 #if defined (HAVE_DECL_FFS) && !HAVE_DECL_FFS
 ~
 extern int ffs(int);
  
 #endif
 ~~   


 /* Get the working directory.  The result is cached, so don't call
 ~~
chdir() between calls to getpwd().  */
~~


 extern char * getpwd (void);
 


 /* Get the current time.  */
 
 /* Prototypes vary from system to system, so we only provide a
 ~~
prototype on systems where we know that we need it.  */
~~~
 #ifdef __MINGW32__
 ~~   
 /* Forward declaration to avoid #include .   */
 ~~~
 struct timeval;
 ~~~  
 extern int gettimeofday (struct timeval *, void *);
 ~~~
 #endif
 ~~   


 /* Get the amount of time the process has run, in microseconds.  */
 ~~~


 extern long get_run_time (void);
 


 /* Generate a relocated path to some installation directory.  Allocates
 ~~~
return value using malloc.  */
~~


 extern char *make_relative_prefix (const char *, const char *,
 ~~
const char *) ATTRIBUTE_MALLOC;
~~~


 /* Generate a relocated path to some 

New Swedish PO file for 'gcc' (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 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-6.1-b20160131.sv.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/gcc/

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/gcc.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 c/70104] New: Should give an error when using multiple case value in switch

[np199113 at gmail dot com]

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

Bug ID: 70104
   Summary: Should give an error when using multiple case value in
switch
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: np199113 at gmail dot com
  Target Milestone: ---

In switch case if one case uses two values it does not give error but multiple
case use two values it gives error.
For example:-
int iswovel(char ch)
{
switch(ch)
{
case 'a' || 'A':
case 'e':
case 'i':
case 'o':
case 'u':return 1;
default:return 0;
}
}
It does not give error But
In this example:-
int iswovel(char ch)
{
switch(ch)
{
case 'a' || 'A':
case 'e' || 'E':
case 'i':
case 'o':
case 'u':return 1;
default:return 0;
}
}
It gives error.

[Bug c++/70096] [6 Regression] [Invalid codegen] Read of uninitialized value in ref-qualified pointer to member function

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Severity|major   |normal

--- Comment #2 from Markus Trippelsdorf  ---
Started with r229018:

commit f16ed232f63165d926986d482708ebf464a04108
Author: jason 
Date:   Tue Oct 20 02:48:43 2015 +

Expand PTRMEM_CST only when necessary.