[Bug target/71470] Wrong code on trunk gcc with westmere target

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|wrong-code  |
 Target|x86_64-pc-linux-gnu |

--- Comment #1 from Andrew Pinski  ---
Can you try this again?  There has been some patches which might have fixed
this.

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[paul.richard.thomas at gmail dot com]

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

--- Comment #15 from paul.richard.thomas at gmail dot com  ---
Dear Ian,

Aaah, OK. I was rather impressed by what you had done with the first bug :-)

For some reason, one of the symbols is not being committed. I will try
and figure out why.

Cheers

Paul

On 18 June 2016 at 17:28, ian_harvey at bigpond dot com
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265
>
> --- Comment #14 from Ian Harvey  ---
> I wouldn't know where to start with respect to the internal compiler error.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c/71583] ICE on invalid code on x86_64-linux-gnu (in c_parser_postfix_expression_after_paren_type, at c/c-parser.c:8192)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code

--- Comment #1 from Andrew Pinski  ---
>gcc-5.3 and older versions do not crash. 

Actually they do:
>small.c:4: confused by earlier errors, bailing out

This is just GCC emitting a message that an ICE occurred after an error message
happened.  GCC emits that message if not configured with checking enabled.

[Bug c/71583] New: ICE on invalid code on x86_64-linux-gnu (in c_parser_postfix_expression_after_paren_type, at c/c-parser.c:8192)

[chengniansun at gmail dot com]

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

Bug ID: 71583
   Summary: ICE on invalid code on x86_64-linux-gnu (in
c_parser_postfix_expression_after_paren_type, at
c/c-parser.c:8192)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

gcc-5.3 and older versions do not crash. 


$: 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/7.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 7.0.0 20160618 (experimental) [trunk revision 237575] (GCC) 
$: 
$: gcc-trunk -c small.c
small.c: In function ‘fn1’:
small.c:4:4: error: expected expression before ‘int’
   {int};
^~~
small.c:4:4: internal compiler error: in
c_parser_postfix_expression_after_paren_type, at c/c-parser.c:8192
0x6ac63f c_parser_postfix_expression_after_paren_type
../../gcc-source-trunk/gcc/c/c-parser.c:8192
0x6a4300 c_parser_cast_expression
../../gcc-source-trunk/gcc/c/c-parser.c:6757
0x6a4374 c_parser_binary_expression
../../gcc-source-trunk/gcc/c/c-parser.c:6580
0x6a5025 c_parser_conditional_expression
../../gcc-source-trunk/gcc/c/c-parser.c:6351
0x6a56a0 c_parser_expr_no_commas
../../gcc-source-trunk/gcc/c/c-parser.c:6268
0x6a5da2 c_parser_expression
../../gcc-source-trunk/gcc/c/c-parser.c:8463
0x6a6809 c_parser_expression_conv
../../gcc-source-trunk/gcc/c/c-parser.c:8496
0x6bcb08 c_parser_statement_after_labels
../../gcc-source-trunk/gcc/c/c-parser.c:5287
0x6be9ab c_parser_compound_statement_nostart
../../gcc-source-trunk/gcc/c/c-parser.c:4861
0x6bf23e c_parser_compound_statement
../../gcc-source-trunk/gcc/c/c-parser.c:4696
0x6c0467 c_parser_declaration_or_fndef
../../gcc-source-trunk/gcc/c/c-parser.c:2105
0x6c9605 c_parser_external_declaration
../../gcc-source-trunk/gcc/c/c-parser.c:1549
0x6c9e99 c_parser_translation_unit
../../gcc-source-trunk/gcc/c/c-parser.c:1430
0x6c9e99 c_parse_file()
../../gcc-source-trunk/gcc/c/c-parser.c:17930
0x72c292 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1070
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.3 small.c
small.c: In function ‘fn1’:
small.c:4:4: error: expected expression before ‘int’
   {int};
^
small.c:4: confused by earlier errors, bailing out
$: 
$: cat small.c
int i;
void fn1() {
  (int(*)[++i]) 
  {int};
}
$:

[Bug c/71581] New: ICE on valid code on x86_64-linux-gnu with -Wuninitialized (Segmentation fault)

[chengniansun at gmail dot com]

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

Bug ID: 71581
   Summary: ICE on valid code on x86_64-linux-gnu with
-Wuninitialized (Segmentation fault)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

This is a regression. gcc-4.9 and gcc-4.8 do not ICE. 

$: 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/7.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 7.0.0 20160618 (experimental) [trunk revision 237575] (GCC) 
$: 
$: gcc-trunk -c small.c -Wuninitialized
small.c: In function ‘fn1’:
small.c:4:1: internal compiler error: Segmentation fault
 }
 ^
0xbbb84f crash_signal
../../gcc-source-trunk/gcc/toplev.c:335
0xdbe07f warn_uninit
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:140
0xdbe3fb warn_uninitialized_vars
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:197
0xdbe730 execute_early_warn_uninitialized
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2449
0xdbe730 execute
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2484
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-trunk -c small.c 
$: 
$: cat small.c
_Complex long double fn1() {
  long double x;
  return x;
}
$:

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

  Attachment #37811|0   |1
is obsolete||

--- Comment #10 from Jerry DeLisle  ---
Created attachment 38723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38723=edit
A better patch

This patch sets a hard limit on the maximum number of copies in a repeat. I
picked a somewhat arbitrary a limit of 1 since this worked on my
machine with out consuming all memory and crippling the system.

[Bug target/71338] [RL78] mulu instruction not used on G10

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
Thanks DJ.  Is it OK to backport it to 5 and 6 branches?  If you're OK with it,
I can do it.

[Bug libfortran/48925] Code cleanup in write_float.def

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Patch posted here:

https://gcc.gnu.org/ml/fortran/2016-06/msg00047.html

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

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

--- Comment #16 from Jerry DeLisle  ---
Patch posted here:

https://gcc.gnu.org/ml/fortran/2016-06/msg00047.html

[Bug c/71552] Confusing error for incorrect struct initialization

[mpeg.blue at free dot fr]

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

--- Comment #5 from Mason  ---
(In reply to Martin Sebor from comment #3)
> In a discussion on gcc-help the submitter provided a different/better test
> case for which GCC could and arguably should emit a better error than
> "initializer element is not constant"

For the record, the test case was provided in comment 2.

Regards.

[Bug c/71552] Confusing error for incorrect struct initialization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2016-06-18
 Resolution|WONTFIX |---
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
In a discussion on gcc-help the submitter provided a different/better test case
for which GCC could and arguably should emit a better error than "initializer
element is not constant:"
  https://gcc.gnu.org/ml/gcc-help/2016-06/msg00057.html

[Bug c/71552] Confusing error for incorrect struct initialization

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01357.html

[Bug fortran/71580] New: Internal compiler error associated with type bound defined assignment

[ian_harvey at bigpond dot com]

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

Bug ID: 71580
   Summary: Internal compiler error associated with type bound
defined assignment
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian_harvey at bigpond dot com
  Target Milestone: ---

With trunk r237470 the following results in an internal compiler error
(sym->backend_decl is null at trans_decl.c:1420).

MODULE MySharedPointer
  IMPLICIT NONE
  PRIVATE

  PUBLIC :: SharedPointer

  TYPE, PRIVATE :: shared_pointer_impl
  CONTAINS
PROCEDURE, PRIVATE :: assign => ptr_impl_assign
GENERIC :: ASSIGNMENT(=) => assign
  END TYPE shared_pointer_impl

  TYPE :: SharedPointer
PRIVATE
TYPE(shared_pointer_impl) :: impl = shared_pointer_impl()
  END TYPE SharedPointer
CONTAINS
  SUBROUTINE ptr_impl_assign(lhs, rhs)
CLASS(shared_pointer_impl), INTENT(OUT) :: lhs
TYPE(shared_pointer_impl), INTENT(IN) :: rhs
  END SUBROUTINE ptr_impl_assign

  SUBROUTINE evil01_worker(x)
TYPE(SharedPointer) :: x
x = make_ptr()
  END SUBROUTINE evil01_worker

  FUNCTION make_ptr() RESULT(ptr)
TYPE(SharedPointer) :: ptr
  END FUNCTION make_ptr
END MODULE MySharedPointer



$ gfortran -v PolyScalarSharedPointerExample.f90
Driving: gfortran -v PolyScalarSharedPointerExample.f90 -l gfortran -l m
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/MEGMS2/ian/usr/gcc-7.0.0/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: .././src/configure --prefix=/home/MEGMS2/ian/usr/gcc-7.0.0
--enable-languages=c,c++,fortran --enable-libgomp --enable-checking=release
Thread model: posix
gcc version 7.0.0 20160615 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/MEGMS2/ian/usr/gcc-7.0.0/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/f951
PolyScalarSharedPointerExample.f90 -quiet -dumpbase
PolyScalarSharedPointerExample.f90 -mtune=generic -march=x86-64 -auxbase
PolyScalarSharedPointerExample -version -fintrinsic-modules-path
/home/MEGMS2/ian/usr/gcc-7.0.0/lib/gcc/x86_64-pc-linux-gnu/7.0.0/finclude -o
/tmp/ccdBc06e.s
GNU Fortran (GCC) version 7.0.0 20160615 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.0.0 20160615 (experimental), GMP version
6.0.0, MPFR version 3.1.3, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 7.0.0 20160615 (experimental)
(x86_64-pc-linux-gnu)
compiled by GNU C version 7.0.0 20160615 (experimental), GMP version
6.0.0, MPFR version 3.1.3, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
PolyScalarSharedPointerExample.f90:30:0:

   END FUNCTION make_ptr

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1420
0x6a1408 gfc_get_symbol_decl(gfc_symbol*)
../.././src/gcc/fortran/trans-decl.c:1420
0x6a370f generate_local_decl
../.././src/gcc/fortran/trans-decl.c:5237
0x66bd2b do_traverse_symtree
../.././src/gcc/fortran/symbol.c:3926
0x6a4372 generate_local_vars
../.././src/gcc/fortran/trans-decl.c:5427
0x6a4372 gfc_generate_function_code(gfc_namespace*)
../.././src/gcc/fortran/trans-decl.c:6106
0x684141 gfc_generate_module_code(gfc_namespace*)
../.././src/gcc/fortran/trans.c:2058
0x63c86b translate_all_program_units
../.././src/gcc/fortran/parse.c:5830
0x63c86b gfc_parse_file()
../.././src/gcc/fortran/parse.c:6049
0x67de02 gfc_be_parse_file
../.././src/gcc/fortran/f95-lang.c:201
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/65248] Copy relocation against protected symbol doesn't work

[nix at esperi dot org.uk]

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

Nix  changed:

   What|Removed |Added

 CC||nix at esperi dot org.uk

--- Comment #9 from Nix  ---
Thirded. At the very least there should be a huge note in binutils NEWS about
this. A subtle, unadvertised incompatibility of a new binutils with a
not-very-old GCC is the sort of horror show that gives free software a bad
name. At the very least make more noise about it.

[Bug libstdc++/71500] regex::icase only works on first character in a range

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||john at johnmaddock dot co.uk

--- Comment #10 from Tim Shen  ---
(In reply to Michael Duggan from comment #9)
> I will make two suggestions.  The initial suggestion is simple enough:
> Given that regex_traits is mandated to be implemented by the library for
> char and wchar_t, it would be reasonable, I think, to make the
> specializations that handled these that go ahead and use the locale.
> This falls into the "as if" rule, where an implementation is fine as
> long as it works "as if" the more correct way was implemented.

> The other suggestion is this.  Given that the more correct is "terribly
> inefficient and impractical", I posit that you have three options: Use
> the "correct", but "bad", implementation, leave the "incorrect in all
> cases" implementation in place, or just go ahead and use the locale to
> implement toggle_case().  Of these three, I think the "incorrect in all
> cases" option is the worst of all worlds.

In long term I think "toggle_case" or its equivalent should be specified by the
user-defined traits. I think we can use my toggle_case for now. I'll post a new
patch to reflect the discussion.

I'll only post the patch after we have an agreement, since I shouldn't bother
the reviewer (sorry Jon!) too frequently. :P

> (It wouldn't be a bad idea to poke the original authors of the regex
> functionality to see what they think.  Apologies in advance if you were
> one of the authors.)

CC'ed John Maddock, the author of Boost.Regex. :)

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[ian_harvey at bigpond dot com]

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

--- Comment #14 from Ian Harvey  ---
I wouldn't know where to start with respect to the internal compiler error.

[Bug target/71375] Failure on startup on rs6000-ibm-aix{4.3|5.1.0}

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
aix52.h overrides TARGET_EXTRA_BUILTINS (sets it to 0); aix43.h and
aix51.h do not.  They probably should.

[Bug c++/70822] [6 Regression] bogus "error: lvalue required as unary ‘&’ operand" with C++14 parenthesized SCOPE_REF

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #3 from David Abdurachmanov  
---
Are there plans to back port this to 6 branch?

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #14 from Eric Botcazou  ---
.

[Bug bootstrap/71578] [7 Regression] segfault during LTO/PGO bootstrap on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
trippels@gcc2-power8 libiberty % cat ../stage_current
stagefeedback
trippels@gcc2-power8 libiberty % cat conf.c
int main (){}
trippels@gcc2-power8 libiberty % /home/trippels/gcc_build_dir_/./prev-gcc/xgcc
-B/home/trippels/gcc_build_dir_/./prev-gcc/
-B/usr/local/powerpc64le-unknown-linux-gnu/bin/ -flto conf.c
In function ‘main’:
lto1: internal compiler error: Segmentation fault
0x10c29997 crash_signal
../../gcc/gcc/toplev.c:335
0x118536d8 input_gimple_stmt
../../gcc/gcc/gimple-streamer-in.c:182
0x118536d8 input_bb(lto_input_block*, LTO_tags, data_in*, function*, int)
../../gcc/gcc/gimple-streamer-in.c:280
0x10943643 input_function
../../gcc/gcc/lto-streamer-in.c:1086
0x10943643 lto_read_body_or_constructor
../../gcc/gcc/lto-streamer-in.c:1223
0x10944637 lto_input_function_body(lto_file_decl_data*, cgraph_node*, char
const*)
../../gcc/gcc/lto-streamer-in.c:1271
0x1037065f cgraph_node::get_untransformed_body()
../../gcc/gcc/cgraph.c:3567
0x10393d07 cgraph_node::expand()
../../gcc/gcc/cgraphunit.c:1953
0x1039482b output_in_order
../../gcc/gcc/cgraphunit.c:2221
0x1039711b symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2469
0x10246443 lto_main()
../../gcc/gcc/lto/lto.c:3328
Please submit a full bug report,

../gcc/configure --enable-gnu-indirect-function --enable-checking=release
--with-cpu=power8 --disable-libstdcxx-pch --disable-libvtv --disable-libitm
--disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror
--enable-multilib --enable-languages=c,c++ --with-build-config="bootstrap-lto
bootstrap-O3"
make -j60 profiledbootstrap

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
Author: ebotcazou
Date: Sat Jun 18 11:10:10 2016
New Revision: 237571

URL: https://gcc.gnu.org/viewcvs?rev=237571=gcc=rev
Log:
PR bootstrap/71435
* reload1.c (reload): Pass 0 to finish_spills when called because
update_eliminables_and_spill returns true and remove did_spill.
(finish_spills): Adjust comment and document GLOBAL parameter.

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

[Bug libstdc++/71579] New: type_traits miss checks for type completeness in some traits

[antoshkka at gmail dot com]

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

Bug ID: 71579
   Summary: type_traits miss checks for type completeness in some
traits
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Completeness is the requirement of C++ Standard. Without completeness check
hard detectable errors are possible:

#include 

struct foo;

void kill_sanity() {
(void)std::is_constructible::value;
}

struct foo{};

int main() {
static_assert(std::is_constructible::value, "foo must be
constructible from foo"); // Oops!
}


All the std::is_*constructible, is_convertible, is_base_of, is_destructible,
is_*swappable, has_virtual_destructor traits are affected.

Minor: multiple triats (like aligned_union and common_type) may have a
static_assert in them, providing a more readable error message in cse of
incomplete type.

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
Created attachment 38722
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38722=edit
Test case

Test case I have prepared for this PR before I saw the problem reported in
comment 8.

The test succeeds with the new patch in comment 9.

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  ---
(In reply to Ian Harvey from comment #10)
> The patch discussed in #5 applies changes to the wrong location in
> trans-decl.c.  Corrected patch attached.  
> 
> With this latest patch I see no variation in check-fortran test results.

Dear Ian,

I agree.

However, the remaining bug in comment #1 is still there. Do you feel up to
trying to fix it?

Best regards

Paul

[Bug c/71552] Confusing error for incorrect struct initialization

[mpeg.blue at free dot fr]

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

--- Comment #2 from Mason  ---
Martin,

Please reconsider this bug's resolution.

In my opinion, "conversion of integers to pointers" is a red herring.

This test case (double vs double ptr) triggers the same confusing error:

struct foo { double *p; };
static double d = 0.5;
struct foo bar = { d }; /*** should be  ***/

$ gcc-6 -c qoi.c
qoi.c:3:20: error: initializer element is not constant
 struct foo bar = { d }; /*** should be  ***/
^
qoi.c:3:20: note: (near initialization for 'bar.p')


My actual code was, in fact, closer to this:

struct xxx { void *p; int a,b,c,d; double x,y; };
struct foo { struct xxx *p; int e,f,g; };
static struct xxx s = { 0 };
struct foo bar = { s }; /*** should be  ***/

$ gcc-6 -c qoi.c
qoi.c:4:20: error: initializer element is not constant
 struct foo bar = { s }; /*** should be  ***/
^
qoi.c:4:20: note: (near initialization for 'bar.p')


In fact, "simple" incorrect initialization triggers the expected error:

struct xxx { void *p; int a,b,c,d; double x,y; };
struct foo { struct xxx *p; int e,f,g; };
static struct xxx s = { 0 };
void func(void)
{
struct xxx *p = s;
}

$ gcc-6 -c qoi.c
qoi.c: In function 'func':
qoi.c:6:18: error:
incompatible types when initializing type 'struct xxx *' using type 'struct
xxx'
  struct xxx *p = s;
  ^

Couldn't struct member initialization be handled the same way?

Regards.

[Bug bootstrap/71578] New: [7 Regression] segfault during LTO/PGO bootstrap on ppc64le

[trippels at gcc dot gnu.org]

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

Bug ID: 71578
   Summary: [7 Regression] segfault during LTO/PGO bootstrap on
ppc64le
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---
Target: ppc64le

trippels@gcc2-power8 libdecnumber % gdb --args
/home/trippels/gcc_build_dir_/./prev-gcc/lto1 -quiet -dumpbase
ccD2SJ3e.ltrans0.o -mcpu=power8 -mcpu=power8 -auxbase-strip
/home/trippels/tmp/ccD2SJ3e.ltrans0.ltrans.o -O3 -O3 -version -fmath-errno
-fsigned-zeros -ftrapping-math -fno-trapv -fno-openmp -fno-openacc
-frandom-seed=1 -fprofile-use
-fltrans-output-list=/home/trippels/tmp/ccD2SJ3e.ltrans.out -fltrans
/home/trippels/tmp/ccD2SJ3e.ltrans0.o -o ccD2SJ3e.ltrans0.s
Reading symbols from /home/trippels/gcc_build_dir_/./prev-gcc/lto1...done.
(gdb) run
Starting program: /home/trippels/gcc_build_dir_/prev-gcc/lto1 -quiet -dumpbase
ccD2SJ3e.ltrans0.o -mcpu=power8 -mcpu=power8 -auxbase-strip
/home/trippels/tmp/ccD2SJ3e.ltrans0.ltrans.o -O3 -O3 -version -fmath-errno
-fsigned-zeros -ftrapping-math -fno-trapv -fno-openmp -fno-openacc
-frandom-seed=1 -fprofile-use
-fltrans-output-list=/home/trippels/tmp/ccD2SJ3e.ltrans.out -fltrans
/home/trippels/tmp/ccD2SJ3e.ltrans0.o -o ccD2SJ3e.ltrans0.s
GNU GIMPLE (GCC) version 7.0.0 20160618 (experimental)
(powerpc64le-unknown-linux-gnu)
compiled by GNU C version 7.0.0 20160618 (experimental), GMP version
6.0.0, MPFR version 3.1.2, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU GIMPLE (GCC) version 7.0.0 20160618 (experimental)
(powerpc64le-unknown-linux-gnu)
compiled by GNU C version 7.0.0 20160618 (experimental), GMP version
6.0.0, MPFR version 3.1.2, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Program received signal SIGSEGV, Segmentation fault.
0x11853878 in input_bb(lto_input_block*, LTO_tags, data_in*, function*,
int) ()
(gdb) bt
#0  0x11853878 in input_bb(lto_input_block*, LTO_tags, data_in*,
function*, int) ()
#1  0x109437e4 in lto_read_body_or_constructor(lto_file_decl_data*,
symtab_node*, char const*, lto_section_type) [clone .isra.54] [clone
.constprop.76] ()
#2  0x109447d8 in lto_input_function_body(lto_file_decl_data*,
cgraph_node*, char const*) ()
#3  0x10370800 in cgraph_node::get_untransformed_body() ()
#4  0x10393ea8 in cgraph_node::expand() ()
#5  0x103978ec in symbol_table::compile() ()
#6  0x102465e4 in lto_main() ()
#7  0x10c28bd4 in compile_file() ()
#8  0x101db4e8 in toplev::main(int, char**) ()
#9  0x101e1498 in main ()

[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|libgcc  |target
   Severity|major   |normal

[Bug libgcc/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[ubizjak at gmail dot com]

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

--- Comment #12 from Uroš Bizjak  ---
(In reply to jos...@codesourcery.com from comment #11)

> There are definitely bugs on some architectures involving ordinary ordered 
> comparisons such as < and >= wrongly using quiet instructions.  See bug 
> 52451 for i386 (x87 floating point) and bug 58684 for powerpc, for 
> example.  A consequence of this is that if you add tests of comparisons 
> doing the right thing, some of those tests would immediately fail on some 
> architectures.

PR 52451 involves x87 compares as well as SSE compares. The invalid (?) compare
mode for x86 target comes from config/i386.c:

--cut here--
/* Figure out whether to use ordered or unordered fp comparisons.
   Return the appropriate mode to use.  */

machine_mode
ix86_fp_compare_mode (enum rtx_code)
{
  /* ??? In order to make all comparisons reversible, we do all comparisons
 non-trapping when compiling for IEEE.  Once gcc is able to distinguish
 all forms trapping and nontrapping comparisons, we can make inequality
 comparisons trapping again, since it results in better code when using
 FCOM based compares.  */
  return TARGET_IEEE_FP ? CCFPUmode : CCFPmode;
}
--cut here--

The "Once gcc is able ..." part in the comment implies that simply returning
different mode based on the incoming rtx code argument won't work. OTOH, this
is ancient comment, so things *could* work now.

Referring to Jakub's observation in Comment #9: As mentioned b HJ, the wrong
mode is due to the above function (PR 37158).

> (These sorts of local bugs with particular operations or optimizations 
> being incorrect regarding exceptions are certainly easier to fix than the 
> issues with optimizations not being aware of exceptions and rounding modes 
> as extra inputs / outputs to floating-point operations.  The ones with 
> individual operations could I expect largely be found through thorough 
> test coverage; those with optimizations might be harder to find.)
> 
> Note that there is some ambiguity about whether LTGT RTL (and 
> corresponding GENERIC / GIMPLE) should be a quiet operation corresponding 
> to islessgreater, or ((x < y) || (x > y)) raising exceptions for quiet 
> NaNs.  See the discussion at 
> .  Fixing 
> the ambiguity in either direction would probably involve changes to the 
> part of the compiler expecting the other semantics.