[Bug inline-asm/68084] Inverted conditions generated for x86 inline assembly "flag output constraints"

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #1 from David  ---
Created attachment 36580
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36580=edit
Possible fix

As I read the code, I think the logic for 'ae' is just backwards.  Try this.

[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
For intrinsics, gcc mostly considers Intel as the standard, so the
documentation would be https://software.intel.com/en-us/node/523865 .

[Bug c++/68087] [5/6 Regression] ICE with constexpr in array with negative index

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-25
 CC||trippels at gcc dot gnu.org
 Blocks||55004
Summary|ICE with constexpr in array |[5/6 Regression] ICE with
   |with negative index |constexpr in array with
   ||negative index
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed.


Referenced Bugs:

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

[Bug target/68088] [6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1782 @ aarch64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-25
 CC||jgreenhalgh at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Introduced with:


r228324 | jgreenhalgh | 2015-10-01 17:33:40 +0800 (Thu, 01 Oct 2015) | 10 lines

[Patch 2/2 ARM/AArch64] Add a new Cortex-A53 scheduling model

* config/arm/aarch-common-protos.h
(aarch_accumulator_forwarding): New.
(aarch_forward_to_shift_is_not_shifted_reg): Likewise.
* config/arm/aarch-common.c (aarch_accumulator_forwarding): New.
(aarch_forward_to_shift_is_not_shifted_reg): Liekwise.
* config/arm/cortex-a53.md: Rewrite.


So actually -mcpu=cortex-a53 and not a57 can allow it to show up on arm*-*-*.

[Bug inline-asm/68084] Inverted conditions generated for x86 inline assembly "flag output constraints"

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Uroš Bizjak  ---
Fixed.

[Bug c++/68087] [5/6 Regression] ICE with constexpr in array with negative index

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Perhaps:

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index ebca411..0828a90 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1782,8 +1782,7 @@ cxx_eval_array_reference (const constexpr_ctx *ctx, tree
t,
   gcc_unreachable ();
 }

-  i = tree_to_shwi (index);
-  if (i < 0)
+  if (!tree_fits_shwi_p (index) || tree_to_shwi (index) < 0)
 {
   if (!ctx->quiet)
error ("negative array subscript");
@@ -1792,6 +1791,7 @@ cxx_eval_array_reference (const constexpr_ctx *ctx, tree
t,
 }

   bool found;
+  i = tree_to_shwi (index);
   if (TREE_CODE (ary) == CONSTRUCTOR)
 {
   HOST_WIDE_INT ix = find_array_ctor_elt (ary, index);

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[vehre at gcc dot gnu.org]

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

--- Comment #9 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sun Oct 25 12:28:57 2015
New Revision: 229294

URL: https://gcc.gnu.org/viewcvs?rev=229294=gcc=rev
Log:
gcc/fortran/ChangeLog:

2015-10-25  Andre Vehreschild  

PR fortran/66927
PR fortran/67044
* trans-array.c (build_array_ref): Modified call to 
gfc_get_class_array_ref to adhere to new interface.
(gfc_conv_expr_descriptor): For one-based arrays that
are filled by a loop starting at one the start index of the
source array has to be mangled into the offset.
* trans-expr.c (gfc_get_class_array_ref): When the tree to get
the _data component is present already, add a way to supply it.
(gfc_copy_class_to_class): Allow to copy to a derived type also.
* trans-stmt.c (gfc_trans_allocate): Do not conv_expr_descriptor
for functions returning a class or derived object. Get the
reference instead.
* trans.h: Interface change of gfc_get_class_array_ref.

gcc/testsuite/ChangeLog:

2015-10-25  Andre Vehreschild  

PR fortran/66927
PR fortran/67044
* gfortran.dg/allocate_with_source_10.f08: New test.
* gfortran.dg/allocate_with_source_11.f08: New test.
* gfortran.dg/class_array_15.f03: Changed count of expected
_builtin_frees to 11. One step of temporaries is spared, therefore
the allocatable component of that temporary is not to be freeed.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_array_15.f03

[Bug fortran/67044] ICE: in aggregate_value_p, at function.c:2068

[vehre at gcc dot gnu.org]

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

--- Comment #3 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sun Oct 25 12:28:57 2015
New Revision: 229294

URL: https://gcc.gnu.org/viewcvs?rev=229294=gcc=rev
Log:
gcc/fortran/ChangeLog:

2015-10-25  Andre Vehreschild  

PR fortran/66927
PR fortran/67044
* trans-array.c (build_array_ref): Modified call to 
gfc_get_class_array_ref to adhere to new interface.
(gfc_conv_expr_descriptor): For one-based arrays that
are filled by a loop starting at one the start index of the
source array has to be mangled into the offset.
* trans-expr.c (gfc_get_class_array_ref): When the tree to get
the _data component is present already, add a way to supply it.
(gfc_copy_class_to_class): Allow to copy to a derived type also.
* trans-stmt.c (gfc_trans_allocate): Do not conv_expr_descriptor
for functions returning a class or derived object. Get the
reference instead.
* trans.h: Interface change of gfc_get_class_array_ref.

gcc/testsuite/ChangeLog:

2015-10-25  Andre Vehreschild  

PR fortran/66927
PR fortran/67044
* gfortran.dg/allocate_with_source_10.f08: New test.
* gfortran.dg/allocate_with_source_11.f08: New test.
* gfortran.dg/class_array_15.f03: Changed count of expected
_builtin_frees to 11. One step of temporaries is spared, therefore
the allocatable component of that temporary is not to be freeed.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_array_15.f03

[Bug fortran/61830] [4.9/5/6 regression] Memory leak with assignment to array of derived types with allocatable components

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
The ICE is fixed by the patch submitted at
https://gcc.gnu.org/ml/fortran/2015-10/msg00117.html.

[Bug c++/68087] New: ICE with constexpr in array with negative index

[roger.ferrer at bsc dot es]

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

Bug ID: 68087
   Summary: ICE with constexpr in array with negative index
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roger.ferrer at bsc dot es
  Target Milestone: ---

Hi,

GCC 6.0.0 20151025 and 5.2 crash with an ICE with the following code:

-- ice.cc
constexpr char c[] = "hello";
constexpr const char *p = c;

void f()
{
static_assert(*(p-1) == 'h', "");
}
-- end of ice.cc

$ g++ --version
g++ (GCC) 6.0.0 20151025 (experimental)
$ g++ -std=c++11 -c ice.cc

ice.cc: In function ‘void f()’:
ice.cc:6:37: internal compiler error: in tree_to_shwi, at tree.c:7304
 static_assert(*(p-1) == 'h', "");
 ^
0xf2fec2 tree_to_shwi(tree_node const*)
../../gcc-git/gcc/tree.c:7304
0x7fc084 cxx_eval_array_reference
../../gcc-git/gcc/cp/constexpr.c:1785
0x7fc084 cxx_eval_constant_expression
../../gcc-git/gcc/cp/constexpr.c:3485
0x7fb18c cxx_eval_indirect_ref
../../gcc-git/gcc/cp/constexpr.c:2588
0x7fb18c cxx_eval_constant_expression
../../gcc-git/gcc/cp/constexpr.c:3340
0x7fe63e cxx_eval_binary_expression
../../gcc-git/gcc/cp/constexpr.c:1601
0x7fa994 cxx_eval_constant_expression
../../gcc-git/gcc/cp/constexpr.c:3462
0x7fff0b cxx_eval_outermost_constant_expr
../../gcc-git/gcc/cp/constexpr.c:3746
0x801980 maybe_constant_value(tree_node*, tree_node*)
../../gcc-git/gcc/cp/constexpr.c:3859
0x772f15 finish_static_assert(tree_node*, tree_node*, unsigned int, bool)
../../gcc-git/gcc/cp/semantics.c:8291
0x6f47a2 cp_parser_static_assert
../../gcc-git/gcc/cp/parser.c:12662
0x70b099 cp_parser_block_declaration
../../gcc-git/gcc/cp/parser.c:11880
0x70bed1 cp_parser_declaration_statement
../../gcc-git/gcc/cp/parser.c:11496
0x70804a cp_parser_statement
../../gcc-git/gcc/cp/parser.c:10162
0x708971 cp_parser_statement_seq_opt
../../gcc-git/gcc/cp/parser.c:10440
0x708a73 cp_parser_compound_statement
../../gcc-git/gcc/cp/parser.c:10394
0x708c00 cp_parser_function_body
../../gcc-git/gcc/cp/parser.c:20216
0x708c00 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-git/gcc/cp/parser.c:20252
0x709929 cp_parser_function_definition_after_declarator
../../gcc-git/gcc/cp/parser.c:24856
0x70a82b cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-git/gcc/cp/parser.c:24768
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.


GCC 5.1 and earlier emit a diagnostic instead:

$ g++-5.1 -std=c++11 -c ice.cc
ice.cc: In function ‘void f()’:
ice.cc:6:5: error: non-constant condition for static assertion
 static_assert(*(p-1) == 'h', "");
 ^
ice.cc:6:5: error: array subscript out of bound

Kind regards,

[Bug target/68088] New: [6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1782 @ aarch64

[zsojka at seznam dot cz]

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

Bug ID: 68088
   Summary: [6 Regression] ICE: RTL check: expected code 'reg',
have 'subreg' in rhs_regno, at rtl.h:1782 @ aarch64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

This ICE happened when building libdebug with an x86_64 -> aarch64
crosscompiler.

RTL checking must be enabled.

$ cc1 -quiet testcase.c -O2 
testcase.c: In function 'foo':
testcase.c:13:5: internal compiler error: RTL check: expected code 'reg', have
'subreg' in rhs_regno, at rtl.h:1782
 }
 ^
0xa90e27 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/mnt/svn/gcc-trunk/gcc/rtl.c:811
0x551cb2 rhs_regno
/mnt/svn/gcc-trunk/gcc/rtl.h:1782
0xe42a00 rhs_regno
/mnt/svn/gcc-trunk/gcc/config/arm/aarch-common.c:429
0xe42a00 aarch_accumulator_forwarding(rtx_insn*, rtx_insn*)
/mnt/svn/gcc-trunk/gcc/config/arm/aarch-common.c:463
0xf08450 internal_insn_latency
   
/home/smatz/build-229293-lto-fortran-checking-yes-rtl-df-disable-bootstrap-disable-graphite-aarch64/gcc/insn-automata.c:22594
0xf08450 insn_latency(rtx_def*, rtx_def*)
   
/home/smatz/build-229293-lto-fortran-checking-yes-rtl-df-disable-bootstrap-disable-graphite-aarch64/gcc/insn-automata.c:23777
0x11075ea dep_cost_1(_dep*, unsigned int)
/mnt/svn/gcc-trunk/gcc/haifa-sched.c:1489
0x11093ef dep_cost
/mnt/svn/gcc-trunk/gcc/haifa-sched.c:1530
0x11093ef priority
/mnt/svn/gcc-trunk/gcc/haifa-sched.c:1681
0x11094f0 set_priorities(rtx_insn*, rtx_insn*)
/mnt/svn/gcc-trunk/gcc/haifa-sched.c:7213
0xaaab8c compute_priorities()
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:2921
0xaadb3d schedule_region
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3014
0xaadb3d schedule_insns
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3412
0xaae2f3 schedule_insns
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3397
0xaae2f3 rest_of_handle_sched
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3616
0xaae2f3 execute
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3724
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.


$ xgcc -v 
Using built-in specs.
COLLECT_GCC=/home/smatz/build-229293-lto-fortran-checking-yes-rtl-df-disable-bootstrap-disable-graphite-aarch64//gcc/xgcc
Target: aarch64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --disable-bootstrap
--enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-229293-lto-fortran-checking-yes-rtl-df-disable-bootstrap-disable-graphite-aarch64/
--without-cloog --without-ppl --without-isl --host=x86_64-pc-linux-gnu
--target=aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--with-sysroot=/home/aarch64-chroot
Thread model: posix
gcc version 6.0.0 20151025 (experimental) (GCC) 


Tested revisions:
r229293 - ICE
5-branch r229292 - OK
4_9-branch r229291 - OK

[Bug target/68088] [6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1782 @ aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Note it might also effect arm*-*-* too but only with -mcpu=cortext-a57 .

[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step

[noloader at gmail dot com]

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

--- Comment #7 from Jeffrey Walton  ---
(In reply to Marc Glisse from comment #6)
> This comment makes no sense (sorry, couldn't find a nice way to say it).
> 
> > Intel builds software
> 
> We are talking about gcc, not Intel software. Documentation is not fast or
> slow.

Yeah, I can understand how it can be confusing. One thing I know is Intel now
documents some of the penalties for using AMD. The FTC required it in their
settlement.

How can we determine what applies, and what does not apply, from the various
Intel docs?

Maybe it would be better if GCC just documented things on its own, and stopped
relying on outside documentation?

> ...
> I was never in favor of documenting those builtins, it makes people believe
> that they can use them...

I thought I was allowed to use documented functions; and I was not supposed to
use undocumented ones. Yeah, this seems to be turned on its head :)

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #12 from Dominique d'Humieres  ---
> See comment 4 of pr59765 for the origin of the problem.
>
> *** This bug has been marked as a duplicate of bug 59765 ***

I don't remember why I have resolved this PR as a duplicate of pr59765. The ICE
is still there with 5.2.0 and trunk (6.0 at r229261). If a duplicate it is more
a duplicate of pr61830: the ICE is fixed by the patch submitted at
https://gcc.gnu.org/ml/fortran/2015-10/msg00117.html.

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[vehre at gcc dot gnu.org]

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

--- Comment #10 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sun Oct 25 13:02:32 2015
New Revision: 229295

URL: https://gcc.gnu.org/viewcvs?rev=229295=gcc=rev
Log:
Added missing testcases of r229294 for patch of
PR fortran/66927.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_10.f08
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_11.f08

[Bug fortran/68078] segfault with allocate and stat for derived types with default initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2015-10-24 00:00:00 |2015-10-25
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). Duplicate of pr59796?

[Bug fortran/68078] segfault with allocate and stat for derived types with default initialization

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Joost VandeVondele  
---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed from 4.8 up to trunk (6.0). Duplicate of pr59796?

pr59796 is a different issue (a deallocate on dangling pointers), which I don't
think is standard conforming. This PR is for standard conforming code, and will
only fail in the presence of default initialization.

[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step

[noloader at gmail dot com]

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

--- Comment #5 from Jeffrey Walton  ---
(In reply to Marc Glisse from comment #4)
> For intrinsics, gcc mostly considers Intel as the standard, so the
> documentation would be https://software.intel.com/en-us/node/523865 .

Thanks Andrew.

Please don't take this in an argumentative manner... Intel is aggressive at
times with respect to anti-competivie practices. Intel builds software that is
fast for its processors, and slow or non-existent for other maker's CPUs.
Microsoft uses Intel intrinsics too, and they even link back to the Intel docs.
Microsoft has lots of footnotes that effectively state "does not work with AMD
CPUs". Confer, check out the use of footnote [2] at
http://msdn.microsoft.com/en-us/library/hh977022.aspx.

Does GCC arbitrarily penalize AMD? Should I just do this in ASM and forgo
builtins/intrinsics?

I had to do it in ASM on Microsoft platforms precisely because of the
anti-competivie practices percolated up from Intel. And using the documented
GCC functions is proving to be more trouble than its worth. I just checked
another Cygwin installation providing X86, and it can't compile the program
either. A copy/paste of the code into NASM is not a hardship.

[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
This comment makes no sense (sorry, couldn't find a nice way to say it).

> Intel builds software

We are talking about gcc, not Intel software. Documentation is not fast or
slow.

> Microsoft has lots of footnotes

Those aren't footnotes.

> that effectively state "does not work with AMD CPUs".

And they have [1] for intrinsics that only work with AMD, not Intel.

> Does GCC arbitrarily penalize AMD?

In what way is anyone penalizing AMD here? Intrinsics are an interface to get
access to specific hardware instructions. They are mostly equivalent to a
suitable inline asm written by knowledgeable compiler writers. Like asm, they
only work on hardware that does provide said instruction. AVX2 intrinsics will
fail on older Intel CPUs. Gcc also provides intrinsics that currently only work
on some AMD CPUs.

> And using the documented GCC functions is proving to be more trouble than its 
> worth.

I was never in favor of documenting those builtins, it makes people believe
that they can use them...

[Bug inline-asm/68084] Inverted conditions generated for x86 inline assembly "flag output constraints"

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-25
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #2 from Uroš Bizjak  ---
Oh, indeed.

I'll fix this in a moment.

[Bug inline-asm/68084] Inverted conditions generated for x86 inline assembly "flag output constraints"

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Oct 25 13:21:01 2015
New Revision: 229296

URL: https://gcc.gnu.org/viewcvs?rev=229296=gcc=rev
Log:
PR target/68084
* config/i386/i386.c (ix86_md_asm_adjust) [case 'a']: Use NE code
for =@ccae.

testsuite/ChangeLog:

PR target/68084
* gcc.target/i386/pr68084.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr68084.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug inline-asm/68014] ICE when using Flag Output Operands

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

   Severity|minor   |enhancement

--- Comment #1 from David  ---
In fact, if someone works on this bug before v6 is released (when all this gets
set in stone), I'd like to suggest an alternative for this 'flags' feature.

In short, I'm wondering if the current approach:

bool boolval;
asm("setc" : "=@ccc"(boolval));

should be changed to something more like:

#define RETURNSCARRY __attribute__((asm_returnconditioncode(carry))

bool boolval = RETURNSCARRY asm("setc" : );

In addition to it being (arguably) easier to read/understand, trying to cram
the flags into an output operand just doesn't fit:

- You can't use %0 inside the template or else you get an ICE (above).
- While the ICE can be fixed, it's not like %0 can actually be used inside the
template, so it isn't really an operand anyway.
- Using "@cc" as a constraint doesn't get rejected by earlier versions of the
compiler.  It compiles, but doesn't do what you expect.  This unnecessarily
opens the door for confusing bugs.
- Using "@cc" as a constraint mucks up multi-alternative.

Possible problems:

- It does remove the ability to return more than 1 condition code from a single
asm, but is that even a thing?
- The return value would need to be treated as an output when determining
whether the asm is volatile.  if (RETURNSCARRY asm("setc" : )) is not volatile,
even though it has 'no' output operands.
- Turning the asm statement into the asm function makes the already "not
standards compliant" extended asm even less standards compliant.

Perhaps internally this would be handled the same (the attribute causes a
'hidden' output operand to get added to the list), but treating it as a return
value is more consistent with how flags work.

[Bug fortran/67171] [6 regression] sourced allocation

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Sun Oct 25 21:31:12 2015
New Revision: 229303

URL: https://gcc.gnu.org/viewcvs?rev=229303=gcc=rev
Log:
2015-01-25  Paul Thomas  

PR fortran/67171
* trans-array.c (structure_alloc_comps): On deallocation of
class components, reset the vptr to the declared type vtable
and reset the _len field of unlimited polymorphic components.
*trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
allocatable component references to the right of part reference
with non-zero rank and return NULL.
(gfc_reset_vptr): Simplify this function by using the function
gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
(gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
NULL return.
* trans-stmt.c (gfc_trans_allocate): Rely on the use of
gfc_trans_assignment if expr3 is a variable expression since
this deals correctly with array sections.

2015-01-25  Paul Thomas  

PR fortran/67171
* gfortran.dg/allocate_with_source_12.f03: New test

PR fortran/61819
* gfortran.dg/allocate_with_source_13.f03: New test

PR fortran/61830
* gfortran.dg/allocate_with_source_14.f03: New test

Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  ---
Author: pault
Date: Sun Oct 25 21:31:12 2015
New Revision: 229303

URL: https://gcc.gnu.org/viewcvs?rev=229303=gcc=rev
Log:
2015-01-25  Paul Thomas  

PR fortran/67171
* trans-array.c (structure_alloc_comps): On deallocation of
class components, reset the vptr to the declared type vtable
and reset the _len field of unlimited polymorphic components.
*trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
allocatable component references to the right of part reference
with non-zero rank and return NULL.
(gfc_reset_vptr): Simplify this function by using the function
gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
(gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
NULL return.
* trans-stmt.c (gfc_trans_allocate): Rely on the use of
gfc_trans_assignment if expr3 is a variable expression since
this deals correctly with array sections.

2015-01-25  Paul Thomas  

PR fortran/67171
* gfortran.dg/allocate_with_source_12.f03: New test

PR fortran/61819
* gfortran.dg/allocate_with_source_13.f03: New test

PR fortran/61830
* gfortran.dg/allocate_with_source_14.f03: New test

Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/61830] [4.9/5/6 regression] Memory leak with assignment to array of derived types with allocatable components

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Sun Oct 25 21:31:12 2015
New Revision: 229303

URL: https://gcc.gnu.org/viewcvs?rev=229303=gcc=rev
Log:
2015-01-25  Paul Thomas  

PR fortran/67171
* trans-array.c (structure_alloc_comps): On deallocation of
class components, reset the vptr to the declared type vtable
and reset the _len field of unlimited polymorphic components.
*trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
allocatable component references to the right of part reference
with non-zero rank and return NULL.
(gfc_reset_vptr): Simplify this function by using the function
gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
(gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
NULL return.
* trans-stmt.c (gfc_trans_allocate): Rely on the use of
gfc_trans_assignment if expr3 is a variable expression since
this deals correctly with array sections.

2015-01-25  Paul Thomas  

PR fortran/67171
* gfortran.dg/allocate_with_source_12.f03: New test

PR fortran/61819
* gfortran.dg/allocate_with_source_13.f03: New test

PR fortran/61830
* gfortran.dg/allocate_with_source_14.f03: New test

Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68092] New: [possibly concepts] ICE: symtab_node::verify failed. Overloaded function by concept requires

[chrisb2244 at gmail dot com]

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

Bug ID: 68092
   Summary: [possibly concepts] ICE: symtab_node::verify failed.
Overloaded function by concept requires
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrisb2244 at gmail dot com
  Target Milestone: ---

Unsure if this is a bug or just bad code on my part. Can't produce a simple
test case.

Class compiles and program runs when using the signature/declaration of a pair
of functions as follows


namespace detail {
enum class enabler {};
}

template
class Mesh
{
public:
template=2, detail::enabler>::type...>
size_t yCells() const { return dimSize_[1]; }
template::type...>
size_t yCells() const { return 0; }
}
/

fails with 
Two symbols with same comdat_group are not linked by the same_comdat_group
list.
template class Mesh<3>;

_ZNK4MeshILm3EE6yCellsEv/711 (size_t Mesh::yCells() const [with long
unsigned int meshDim = 3ul]) @address
  Type: function definition analyzed
  Visibility: forced_by_abi public weak comdat_group:_ZNK4MeshILm3EE6yCellsEv
one_only
  previous sharing asm name: 710
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: 
  Calls: 
_ZN_ZNK4MeshILm3EE6yCellsEv/710 (size_t Mesh::yCells() const requires
predicate( true) [with long unsigned int meshDim = 3ul]) @0x7f20e64268a0
  Type: function definition analyzed
  Visibility: forced_by_abi public weak comdat_group:_ZNK4MeshILm3EE6yCellsEv
one_only
  next sharing asm name: 711
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: 
  Calls: _ZNKSt6vectorImSaImEEixEm/1078 (1.00 per call) 
<...>/Mesh.cpp:183:23: internal compiler error: symtab_node::verify failed
0x904339 symtab_node::verify_symtab_nodes()
../../gcc-svn-sources/gcc/symtab.c:1126


when using either of
///
size_t yCells() const requires true { return dimSize_[1]; }
size_t yCells() const { return 0; }
///
template
concept bool Mesh2D() {
return N>=2;
}

template
class Mesh
{
public:
size_t yCells() const requires Mesh2D() { return dimSize_[1]; }
size_t yCells() const { return 0; }
/

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #14 from Paul Thomas  ---
Fixed on trunk - I'll see what I can do for the earlier branches.

Thanks for the report

Paul

[Bug fortran/61830] [4.9/5/6 regression] Memory leak with assignment to array of derived types with allocatable components

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Fixed on trunk - I'll see what I can do for the earlier branches.

Thanks for the report

Paul

[Bug c++/67918] -fdevirtualize causes binary to crash with Segmentation Fault (CryptoPP involved)

[11throwaway11 at outlook dot com]

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

--- Comment #6 from Nameless <11throwaway11 at outlook dot com> ---
Another update:

In Crypto++ there was a class with a virtual function, in a header file:
https://github.com/weidai11/cryptopp/blob/b7de164d6251dc066123b59bc15d30c74e920756/modes.h#L71

There were two derived classes that overridden this function, but called the
version of the base class:
1)
https://github.com/weidai11/cryptopp/blob/b7de164d6251dc066123b59bc15d30c74e920756/modes.h#L173
2)
https://github.com/weidai11/cryptopp/blob/b7de164d6251dc066123b59bc15d30c74e920756/modes.h#L232

Moving definitions of these functions from a header file to a .cpp-file and
recompiling the library made the testcase work:
https://github.com/weidai11/cryptopp/commit/8134f2cd502e457201d65f1dc557268ba13e3663

Worth noting that only -fdevirtualize is actually not enough, it's a
combination of -O1 and -fdevirtualize. -O0 -fdevirtualize doesn't crash.

I couldn't narrow it down to a specific -O1 optimization, because applying all
those flags mentioned under -O1:
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

... did not make the output binary crash. I guess it's a case of "Not all
optimizations are controlled directly by a flag. Only optimizations that have a
flag are listed in this section. Most optimizations are only enabled if an -O
level is set on the command line".

[Bug fortran/67528] Wrong result with defined assignment operator and/or parenthesized expressions and allocatable components

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  ---
AFAICT this PR is fixed after revision r229303.

[Bug c++/68092] [possibly concepts] ICE: symtab_node::verify failed. Overloaded function by concept requires

[chrisb2244 at gmail dot com]

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

--- Comment #2 from Christian Butcher  ---
Created attachment 36582
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36582=edit
main function (1/3)

First of 3 files to demonstrate problem. (Not)Compiled with g++ -std=c++1z
conceptFunctionOverload.cpp class.cpp

Errors with:

class.cpp:13:26: error: Two symbols with same comdat_group are not linked by
the same_comdat_group list.
 template class myClass<1>;
  ^
_ZNK7myClassILm1EE3fooEv/493 (int myClass::foo() const [with long unsigned
int N = 1ul]) @0x7f2e61df0b80
  Type: function definition analyzed
  Visibility: forced_by_abi public weak comdat_group:_ZNK7myClassILm1EE3fooEv
one_only
  previous sharing asm name: 492
  References: _ZSt4cout/1176
(addr)_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_/805 (addr)
  Referring: 
  First run: 0
  Function flags: body
  Called by: 
  Calls: _ZNKSt6vectorIiSaIiEEixEm/807 (1.00 per call) _ZNSolsEPFRSoS_E/806
(1.00 per call) (can throw external) _ZNSolsEm/804 (1.00 per call) (can throw
external) _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc/803 (1.00 per
call) (can throw external) 
_ZNK7myClassILm1EE3fooEv/492 (int myClass::foo() const requires
predicate((ConceptTest)()) [with long unsigned int N = 1ul]) @0x7f2e61df0a10
  Type: function definition analyzed
  Visibility: forced_by_abi public weak comdat_group:_ZNK7myClassILm1EE3fooEv
one_only
  next sharing asm name: 493
  References: _ZSt4cout/1176
(addr)_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_/805 (addr)
  Referring: 
  First run: 0
  Function flags: body
  Called by: 
  Calls: _ZNKSt6vectorIiSaIiEEixEm/807 (1.00 per call) _ZNSolsEPFRSoS_E/806
(1.00 per call) (can throw external) _ZNSolsEm/804 (1.00 per call) (can throw
external) _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc/803 (1.00 per
call) (can throw external) 
class.cpp:13:26: internal compiler error: symtab_node::verify failed
0x904339 symtab_node::verify_symtab_nodes()
../../gcc-svn-sources/gcc/symtab.c:1126
0x9169f5 symbol_table::compile()
../../gcc-svn-sources/gcc/cgraphunit.c:2377
0x919687 symbol_table::compile()
../../gcc-svn-sources/gcc/cgraphunit.c:2536
0x919687 symbol_table::finalize_compilation_unit()
../../gcc-svn-sources/gcc/cgraphunit.c:2562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/68092] [possibly concepts] ICE: symtab_node::verify failed. Overloaded function by concept requires

[chrisb2244 at gmail dot com]

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

--- Comment #4 from Christian Butcher  ---
Created attachment 36584
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36584=edit
Class cpp

[Bug c++/68092] [possibly concepts] ICE: symtab_node::verify failed. Overloaded function by concept requires

[chrisb2244 at gmail dot com]

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

--- Comment #3 from Christian Butcher  ---
Created attachment 36583
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36583=edit
Class header

[Bug c++/68094] New: Compiler segmentation fault

[baqwas at gmail dot com]

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

Bug ID: 68094
   Summary: Compiler segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baqwas at gmail dot com
  Target Milestone: ---

Created attachment 36585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36585=edit
Pre-processed source with error report

Compiler issues segmentation fault for very nominal lines of code as shown in
the attachment. Compiler invoked through Arduino IDE (2:1.0.5+dfsg2-4) running
under Debian Jessie on Raspberry Pi 2 platform.

Arduino IDE under Windows 10 does not exhibit any error.

Arduino installed using standard apt-get install command after the customary
update/upgrade steps. Was able to run Arduino IDE successfully under Debian
Wheezy on same platform.

My apologies if this is a "newbie" error but I did not find any equivalent bugs
reported previously.

[Bug target/68091] [6 Regression] [SH] internal compiler error: in expand_vec_cond_expr, at optabs.c:5391

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #1 from Oleg Endo  ---
Actually, I was thinking of adding vector move insns because otherwise it seems
difficult to add support for the e.g. fipr instruction (PR 55295).  Also, if I
remember correctly, PR 13423 can be improved by adding the corresponding vector
move insns.

However, I don't know when I will have time to work on this.  I think changing
it to TARGET_SHMEDIA condition is the way to go for now.

[Bug c++/68093] New: [concepts] friend function declarations that differ only by constraints are rejected as redefinitions

[tom at honermann dot net]

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

Bug ID: 68093
   Summary: [concepts] friend function declarations that differ
only by constraints are rejected as redefinitions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
  Target Milestone: ---

I believe the following code is intended to be well-formed according to P0121r0
[1].  gcc trunk (r229299) currently rejects it.

$ cat t.cpp
struct S1 {};
struct S2 { using t1 = int; };
template
concept bool Has_t1() {
return requires () { typename T::t1; };
}
template
struct TS {
friend void f(TS) {}
friend void f(TS) requires Has_t1() {} // Unexpected error: redefinition
};
TS ts1;
TS ts2;
auto x = []{
 f(ts1);
 f(ts2);
 };

$ gcc --version
gcc (GCC) 6.0.0 20151025 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -c -std=c++1z t.cpp 
t.cpp: In instantiation of ‘struct TS’:
t.cpp:12:8:   required from here
t.cpp:10:17: error: redefinition of ‘void f(TS)’
 friend void f(TS) requires Has_t1() {} // Unexpected error:
redefinition
 ^
t.cpp:9:17: note: ‘void f(TS)’ previously defined here
 friend void f(TS) {}
 ^
t.cpp: In instantiation of ‘struct TS’:
t.cpp:13:8:   required from here
t.cpp:10:17: error: redefinition of ‘void f(TS)’
 friend void f(TS) requires Has_t1() {} // Unexpected error:
redefinition
 ^
t.cpp:9:17: note: ‘void f(TS)’ previously defined here
 friend void f(TS) {}
 ^

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0121r0.pdf

[Bug fortran/67171] [6 regression] sourced allocation

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Paul Thomas  ---
Fixed on trunk.

Thanks for the report.

Paul

[Bug c++/68092] [possibly concepts] ICE: symtab_node::verify failed. Overloaded function by concept requires

[chrisb2244 at gmail dot com]

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

--- Comment #1 from Christian Butcher  ---
Will keep working on a (non-compilable) test case. If someone is interested,
can upload full sources for this class

[Bug c++/68092] [possibly concepts] ICE: symtab_node::verify failed. Overloaded function by concept requires

[chrisb2244 at gmail dot com]

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

--- Comment #5 from Christian Butcher  ---
Comment 2 has the wrong error (previous testcase with cout statements)

Correct error:

class.cpp:13:26: error: Two symbols with same comdat_group are not linked by
the same_comdat_group list.
 template class myClass<1>;
  ^
_ZNK7myClassILm1EE3fooEv/493 (int myClass::foo() const [with long unsigned
int N = 1ul]) @0x7f9a42be1b80
  Type: function definition analyzed
  Visibility: forced_by_abi public weak comdat_group:_ZNK7myClassILm1EE3fooEv
one_only
  previous sharing asm name: 492
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: 
  Calls: _ZNKSt6vectorIiSaIiEEixEm/803 (1.00 per call) 
_ZNK7myClassILm1EE3fooEv/492 (int myClass::foo() const requires
predicate((ConceptTest)()) [with long unsigned int N = 1ul]) @0x7f9a42be1a10
  Type: function definition analyzed
  Visibility: forced_by_abi public weak comdat_group:_ZNK7myClassILm1EE3fooEv
one_only
  next sharing asm name: 493
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: 
  Calls: _ZNKSt6vectorIiSaIiEEixEm/803 (1.00 per call) 
class.cpp:13:26: internal compiler error: symtab_node::verify failed
0x904339 symtab_node::verify_symtab_nodes()
../../gcc-svn-sources/gcc/symtab.c:1126
0x9169f5 symbol_table::compile()
../../gcc-svn-sources/gcc/cgraphunit.c:2377
0x919687 symbol_table::compile()
../../gcc-svn-sources/gcc/cgraphunit.c:2536
0x919687 symbol_table::finalize_compilation_unit()
../../gcc-svn-sources/gcc/cgraphunit.c:2562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/68091] New: [6 Regression] [SH] internal compiler error: in expand_vec_cond_expr, at optabs.c:5391

[kkojima at gcc dot gnu.org]

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

Bug ID: 68091
   Summary: [6 Regression] [SH] internal compiler error: in
expand_vec_cond_expr, at optabs.c:5391
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kkojima at gcc dot gnu.org
  Target Milestone: ---
Target: sh4*-*-*

The recent change of middle-end for vector operations causes some new
ICEs in the testsuite on sh4.  A Typical one is:

trunk/gcc/testsuite/g++.dg/ext/vector27.C:12:16: internal compiler error: in
expand_vec_cond_expr, at optabs.c:5391
0x877369f expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*,
rtx_def*)
../../ORIG/trunk/gcc/optabs.c:5390
0x8588a0e do_store_flag
../../ORIG/trunk/gcc/expr.c:11052
0x8588a0e expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../ORIG/trunk/gcc/expr.c:9010
0x846bb89 expand_gimple_stmt_1
../../ORIG/trunk/gcc/cfgexpand.c:3617

It seems that the middle-end change reveals a target problem that
sh_vector_mode_supported_p returns true even the target has no mov
insns for some vector modes.

 bool
 sh_vector_mode_supported_p (machine_mode mode)
 {
   if (TARGET_FPU_ANY
   && ((mode == V2SFmode)
  || (mode == V4SFmode)
  || (mode == V16SFmode)))
 return true;
   ...

It looks that this TARGET_FPU_ANY should be TARGET_SHMEDIA_FPU in
the first place, because all movv* patterns in sh.md are written for
SHMEDIA only.  The ICEs seen only on sh4 went away with replacing
TARGET_FPU_ANY with TARGET_SHMEDIA_FPU in sh_vector_mode_supported_p.
Although I know that we shouldn't add the new sh5 hunks, I think
that this change is rather a preparation to zap them out.

[Bug inline-asm/68095] New: "cc" clobber with Flag Output Operands

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 68095
   Summary: "cc" clobber with Flag Output Operands
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com
  Target Milestone: ---

Normally when trying to use a register and clobber it at the same time, the
compiler kicks out an error (operand has impossible constraints).  However that
doesn't happen when using Flag Output Operands and the "cc" clobber:

  asm ("cmp %2, %1" : "=@ccc"(r) : "m"(*p), "ri"(2): "cc");

Should this be a conflict?

On the other hand, the asm is changing the flags.  So is the "cc" *required*? 
But it doesn't seem to be:

  asm ("cmp %2, %1" : "=@ccc"(r) : "m"(*p), "ri"(2));

Now that asm flags are a real thing, we should pick one and enforce it.

[Bug middle-end/68079] hppa: pointers to method types need canonicalization before comparison

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Author: danglin
Date: Sun Oct 25 15:18:48 2015
New Revision: 229299

URL: https://gcc.gnu.org/viewcvs?rev=229299=gcc=rev
Log:
PR middle-end/68079
* dojump.c (do_compare_and_jump): Canonicalize both function and
method types.


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

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[vehre at gcc dot gnu.org]

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

--- Comment #12 from vehre at gcc dot gnu.org ---
I can confirm that issue. Don't know how to fix it yet, though. Looks like the
scalarizer is not coping correctly with a AS_DEFERRED array.

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
On Linux/ia32, I got

spawn [open ...]^M
*** Error in `./allocate_with_source_10.exe': free(): invalid next size (fast):
0x09dcebc8 ***

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0xf7766bdf in ???
#1  0x456e2e68 in ???
#2  0x456e5a03 in ???
#3  0x456e7c5e in ???
#4  0x45658960 in ???
#5  0x4565ebf2 in ???
#6  0x4565a4e3 in ???
#7  0x4565e481 in ???
#8  0x457a35fb in ???
#9  0x4565a4e3 in ???
#10  0x457a36f0 in ???
#11  0x45777192 in ???
#12  0x45777424 in ???
#13  0x45688969 in ???
#14  0x456dbf12 in ???
#15  0x456e4899 in ???
#16  0x456e7f3f in ???
#17  0x804916e in ???
#18  0x80492a2 in ???
#19  0x80492e2 in ???
#20  0x456896f4 in ???
#21  0x8048780 in ???
FAIL: gfortran.dg/allocate_with_source_10.f08   -O0  execution test

GCC is configured with

--prefix=/usr/6.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-libmpx i686-linux --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto,objc

[Bug fortran/36192] ICE with wrong index types and bad parens

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #12 from kargl at gcc dot gnu.org ---
I have a patch that cures at segfault on the reduced testcase.

[Bug fortran/61830] [4.9/5/6 regression] Memory leak with assignment to array of derived types with allocatable components

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #6 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #5)
> The ICE is fixed by the patch submitted at
> https://gcc.gnu.org/ml/fortran/2015-10/msg00117.html.

The "memory leak" comes about because of the POINTER component map. This
allocation is still accessible at termination and is fixed by:

...snip
! This gets rid of the "memory leak"
  if (associated (u%u(1)%map)) deallocate (u%u(1)%map)
  call free_v_field(u)
  call v%free()
  deallocate(av)
end program

[Bug ipa/67600] [5/6 Regression] Segfault when assigning only one char to ostreambuf_iterator compiled with -O2 or -O3

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #8 from H.J. Lu  ---
(In reply to Markus Trippelsdorf from comment #7)
> (In reply to Mikhail Maltsev from comment #6)
> > I wonder if the testcase could be reduced somehow...
> > 
> > $ ll -S gcc/testsuite/g++.dg/torture | head -n 7
> > total 2.2M
> > -rw-r--r-- 1 miyuki miyuki 664K  19:44  24.10.15 pr67600.C
> 
> Yeah, I was wondering about that too. 
> Honza, why are not just using two #includes instead of all the preprocessed
> standard headers?

I don't think we can pass prepossessed C++ to g++ as C++.
We got:

FAIL: g++.dg/torture/pr67600.C   -O0  (test for excess errors)
Excess errors:
In file included from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/stl_algobase.h:61:0,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/char_traits.h:39,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/ios:40,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/ostream:38,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/iostream:39,
 from t.C:1:
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/cpp_type_traits.h:259:40:
error: template argument 1 is invalid
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/cpp_type_traits.h:259:145:
error: template argument 1 is invalid
In file included from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/move.h:57:0,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/stl_pair.h:59,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/stl_algobase.h:64,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/char_traits.h:39,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/ios:40,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/ostream:38,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/iostream:39,
 from t.C:1:
/aux/hubicka/trunk-install/include/c++/6.0.0/type_traits:258:41: error:
template argument 1 is invalid
/aux/hubicka/trunk-install/include/c++/6.0.0/type_traits:262:50: error:
template argument 1 is invalid
In file included from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/move.h:57:0,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/stl_pair.h:59,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/stl_algobase.h:64,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/char_traits.h:39,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/ios:40,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/ostream:38,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/iostream:39,
 from t.C:1:
/aux/hubicka/trunk-install/include/c++/6.0.0/type_traits:317:39: error:
'__float128' was not declared in this scope
/aux/hubicka/trunk-install/include/c++/6.0.0/type_traits:317:49: error:
template argument 1 is invalid
In file included from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/move.h:57:0,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/stl_pair.h:59,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/stl_algobase.h:64,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/char_traits.h:39,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/ios:40,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/ostream:38,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/iostream:39,
 from t.C:1:
/aux/hubicka/trunk-install/include/c++/6.0.0/type_traits:1704:36: error:
template argument 1 is invalid
In file included from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/move.h:57:0,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/stl_pair.h:59,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/stl_algobase.h:64,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/char_traits.h:39,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/ios:40,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/ostream:38,
 from /aux/hubicka/trunk-install/include/c++/6.0.0/iostream:39,
 from t.C:1:
/aux/hubicka/trunk-install/include/c++/6.0.0/type_traits:1823:43: error:
template argument 1 is invalid
In file included from
/aux/hubicka/trunk-install/include/c++/6.0.0/ext/new_allocator.h:33:0,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
 from
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/allocator.h:46,
 from 

[Bug middle-end/68079] hppa: pointers to method types need canonicalization before comparison

[danglin at gcc dot gnu.org]

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

--- Comment #7 from John David Anglin  ---
Author: danglin
Date: Sun Oct 25 15:45:33 2015
New Revision: 229301

URL: https://gcc.gnu.org/viewcvs?rev=229301=gcc=rev
Log:
PR middle-end/68079
* dojump.c (do_compare_and_jump): Canonicalize both function and
method types.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/dojump.c

[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #4 from Paul Thomas  ---
The result from the reshape call is completely screwed up. The temporary, is
descriptor, whose data field is class objects, rather than returning the _data
field of the class object.

I can see how to fix this.

Paul

[Bug middle-end/68079] hppa: pointers to method types need canonicalization before comparison

[danglin at gcc dot gnu.org]

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

--- Comment #6 from John David Anglin  ---
Author: danglin
Date: Sun Oct 25 15:42:19 2015
New Revision: 229300

URL: https://gcc.gnu.org/viewcvs?rev=229300=gcc=rev
Log:
PR middle-end/68079
* dojump.c (do_compare_and_jump): Canonicalize both function and
method types.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/dojump.c

[Bug middle-end/68079] hppa: pointers to method types need canonicalization before comparison

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #5 from John David Anglin  ---
Fixed on trunk.

[Bug c++/68089] New: c++ friend with template

[dushistov at mail dot ru]

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

Bug ID: 68089
   Summary: c++ friend with template
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dushistov at mail dot ru
  Target Milestone: ---

Here is code:
#include 

template
class C
{
template // 
friend class C;

template
friend bool operator == (C const& c1, C const& c2)
{
  return c1.i == c2.i;
}

int i;

  public:

C(): i {0} {}
C(int val): i {val} {}
}; // template class C

int main()
{
  C  c1 {5};
  C c2 {5};

  if (c1 == c2) std::cout << "All ok" << std::endl;
  else  std::cout << "Very bad" << std::endl;



  return 0;
}

compile line:
g++ -Wall -std=c++14 test4.cpp
g++ -Wall -std=c++14 test4.cpp
test4.cpp: In instantiation of 'bool operator==(const C&, const C&) [with
U = char; T = int]':
test4.cpp:28:13:   required from here
test4.cpp:15:9: error: 'int C::i' is private
 int i;
 ^
test4.cpp:12:19: error: within this context
   return c1.i == c2.i;

so even if bool operator == (C const& c1, C const& c2) is friend of
template class C; it not allowed to access C<>::i,
but clang compiles this code without errors.

[Bug c/68090] New: VLA compound literal -- "confused by earlier errors, bailing out"

[ch3root at openwall dot com]

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

Bug ID: 68090
   Summary: VLA compound literal  -- "confused by earlier errors,
bailing out"
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Compiling the following program:

int main() { (int [(0,1)]){0}; }

produce this:

compound-vla.c: In function ‘main’:
compound-vla.c:1:14: error: compound literal has variable size
 int main() { (int [(0,1)]){0}; }
  ^
compound-vla.c:1: confused by earlier errors, bailing out

The error message is fine but it should not "confuse" the compiler.