[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

--- Comment #24 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #23)
> Ok I see it.
> 
> In fbuf.c (fbuf_alloc):
> 
>   /* Round up to nearest multiple of the current buffer length.  */
>   newlen = ((u->fbuf->pos + len) / u->fbuf->len + 1) *u->fbuf->len;
>   u->fbuf->buf = xrealloc (u->fbuf->buf, newlen);
>   u->fbuf->len = newlen;
> 
> We are rounding up to make sure we have enough buffer. The size newlen is
> calculated to 2147484160 which exceeds the limit of 2147483647 and xrealloc
> fails.

There is a 2 GB limit on 32 bit processes, so this is not a bug. I suggest this
be closed.

[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

--- Comment #23 from Jerry DeLisle  ---
Ok I see it.

In fbuf.c (fbuf_alloc):

  /* Round up to nearest multiple of the current buffer length.  */
  newlen = ((u->fbuf->pos + len) / u->fbuf->len + 1) *u->fbuf->len;
  u->fbuf->buf = xrealloc (u->fbuf->buf, newlen);
  u->fbuf->len = newlen;

We are rounding up to make sure we have enough buffer. The size newlen is
calculated to 2147484160 which exceeds the limit of 2147483647 and xrealloc
fails.

[Bug tree-optimization/84929] New: ICE at -O3 on valid code on x86_64-linux-gnu: tree check: expected polynomial_chrec, have nop_expr in analyze_siv_subscript_cst_affine, at tree-data-ref.c:3018

[helloqirun at gmail dot com]

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

Bug ID: 84929
   Summary: ICE at -O3 on valid code on x86_64-linux-gnu: tree
check: expected polynomial_chrec, have nop_expr in
analyze_siv_subscript_cst_affine, at
tree-data-ref.c:3018
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

It happens at -O3. "-O2" works fine.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 8.0.1 20180317 (experimental) [trunk revision 258620] (GCC)


$ gcc-trunk -O3 abc.c
during GIMPLE pass: pcom
abc.c: In function ‘fn1’:
abc.c:2:6: internal compiler error: tree check: expected polynomial_chrec, have
nop_expr in analyze_siv_subscript_cst_affine, at tree-data-ref.c:3018
 void fn1() {
  ^~~
0x6f05ca tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9322
0x76fe1b analyze_siv_subscript_cst_affine
../../gcc/gcc/tree.h:3135
0x1514588 analyze_siv_subscript
../../gcc/gcc/tree-data-ref.c:3898
0x1514588 analyze_overlapping_iterations
../../gcc/gcc/tree-data-ref.c:4153
0x1514588 subscript_dependence_tester_1
../../gcc/gcc/tree-data-ref.c:4694
0x1514a37 subscript_dependence_tester_1
../../gcc/gcc/tree-data-ref.c:4690
0x1514a37 subscript_dependence_tester
../../gcc/gcc/tree-data-ref.c:4744
0x1514a37 compute_affine_dependence(data_dependence_relation*, loop*)
../../gcc/gcc/tree-data-ref.c:4803
0x151661c compute_all_dependences(vec<data_reference*, va_heap, vl_ptr>,
vec<data_dependence_relation*, va_heap, vl_ptr>*, vec<loop*, va_heap, vl_ptr>,
bool)
../../gcc/gcc/tree-data-ref.c:4870
0x1516e0a compute_data_dependences_for_loop(loop*, bool, vec<loop*, va_heap,
vl_ptr>*, vec<data_reference*, va_heap, vl_ptr>*,
vec<data_dependence_relation*, va_heap, vl_ptr>*)
../../gcc/gcc/tree-data-ref.c:5269
0xd7d589 tree_predictive_commoning_loop
../../gcc/gcc/tree-predcom.c:3190
0xd805dd tree_predictive_commoning()
../../gcc/gcc/tree-predcom.c:3312
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ cat abc.c
int a[4];
void fn1() {
  unsigned long b = 7818038963515661296;
  for (;; b++)
a[0xA699ECD2C348A3A0] = a[b];
}

[Bug libstdc++/84928] std::accumulate should move the accumulator argument

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This isn't a bug, because that change has only been in the working draft for a
few months, and is not part of any published standard yet.

https://wg21.link/p0616R0

Re: Strict aliasing-related bug even with optimizations disabled

[Andrew Pinski]

On Sat, Mar 17, 2018 at 11:40 AM, Jonathon Reinhart
 wrote:
> This was originally posted on Stack Overflow:
> https://stackoverflow.com/a/49339771/119527
>
> The following program:
>
> #include 
>
> static void pshort(short val)
> {
>printf("0x%hx ", val);
> }
>
> int main(void)
> {
>short A[] = {1, 2, 3, 4, 5, 6};
>
> #define EXP ((short*)((char*)A + 7))
>
>short *p = EXP;
>short q = *EXP;
>
>pshort(*p);
>pshort(q);
>pshort(*EXP);
>printf("\n");
>
>return 0;
> }
>
> ...when compiled on x86-64 with
>
> gcc -O0 -fno-strict-aliasing -g -Wall -Werror endian.c
>
> ...produces the following unexpected output
>
> 0x500 0x500 0x4
>
> ...on all available versions of GCC, from 4.9 thru 7.3.1.
>
> It appears that GCC is actually generating different code when the
> expression is used directly as an argument, versus when used with
> intermediate variables.
>
> The language lawyers declared that UB is UB. But -fno-strict-aliasing
> seems to be ineffective here, and this feels like a bug.


As mentioned this is the right mailing list for this kind of question.
But this is undefined not due to aliasing but alignment reasons.
short has an alignment requirement of 2 while you made it unaligned.

Thanks,
Andrew

>
> Jonathon Reinhart

Re: Strict aliasing-related bug even with optimizations disabled

[Jonathan Wakely]

On 17/03/18 14:40 -0400, Jonathon Reinhart wrote:

This was originally posted on Stack Overflow:
https://stackoverflow.com/a/49339771/119527


This mailing list is for automated emails from Bugzilla, not for
reporting bugs. Please use Bugzilla to report bugs, as explained at
https://gcc.gnu.org/bugs

However, this doesn't look like a bug. -fstrict-aliasing isn't enabled
without optimization anyway, and -fno-strict-aliasing doesn't mean
"allow undefined nonsense".

[Bug other/84889] Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
(In reply to David Malcolm from comment #5)
> Note to self: need to look at Elm.

http://elm-lang.org/blog/compiler-errors-for-humans

http://elm-lang.org/blog/compilers-as-assistants

[Bug c++/84269] More suggestions for missing #include

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
(In reply to David Malcolm from comment #4)
> And another, as reported at
> https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/
> dvtl76x/
> 
> > const auto s = strlen("test");
> > with gcc (trunk) gives the following error:
> > [x86-64 gcc (trunk) #1] error: 'strlen' was not declared in this scope
> > [x86-64 gcc (trunk) #1] note: suggested alternative: 'struct'

Confirmed (with r258277).  We definitely shouldn't suggest "struct" here, which
feels reminiscent of PR c++/81610 and PR c++/80567, but which appears to still
be unfixed.

[Bug c++/84269] More suggestions for missing #include

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

Summary|C++ FE does not suggest |More suggestions for
   |which #include to use for   |missing #include
   |"memset"|

--- Comment #4 from David Malcolm  ---
And another, as reported at
https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/dvtl76x/

> const auto s = strlen("test");
> with gcc (trunk) gives the following error:
> [x86-64 gcc (trunk) #1] error: 'strlen' was not declared in this scope
> [x86-64 gcc (trunk) #1] note: suggested alternative: 'struct'

Many of these likely apply to the C frontend as well.

[Bug other/26061] error and warning count

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

  Component|middle-end  |other
   Target Milestone|--- |9.0

[Bug other/44032] internals documentation is not legally safe to use

[amylaar at gcc dot gnu.org]

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

--- Comment #4 from Jorn Wolfgang Rennecke  ---
(In reply to Eric Gallager from comment #3)
> Is this fixed in the same way that bug 44035 was fixed?

No. 44035 was about the inability to fix, 44032 is about the
actual licensing state of the documentation.  A brief look at
gccint.texi shows that this file remains purely GFDL.
I suppose there are numerous other files likewise affected.

It can only be considered fixed if all the parts of existing
documentation that you might conceivably want to cut & paste into
GPLed code are suitably re-licensed, and we have put something in
place that the issue will generally not appear with new GCC
documentation.

If all documentation files that come with GCC were patched as
suggested in comment #2, that could be considered a solution,
as people who cut & paste the copyright blurb for new files
would pick up the new text.  Well, there might be a transition
period when backed-up patches and patches made with using older
baselines need to be vetted for necessary adjustments.

If only some documentation files are patches to have the
amended copyright blurb, as others have no applicable code
samples, the others should have a warning not to copy them to
new files that will have such samples.

[Bug fortran/84615] [8 Regression] Executable Segfault for some tests compiled with -m32 after r256284

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
The following variant without module of the test in comment 8 behaves the same
way

program TestStringTools
  character(len=52)   :: txt
  character(len=1), dimension(52) :: chararr = &
(/(char(i+64),char(i+96), i = 1,26)/)
  print *, ">", chararr, "<"
  txt = chararray2string(chararr)
  if (txt .ne. "AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz") &
STOP 1
contains
  function chararray2string(chararray) result(text)
character(len=1), dimension(:) :: chararray! input
character(len=int(size(chararray, 1), kind=8)) :: text  ! output
print *, ">", chararray, "<"
do i = 1,size(chararray,1)
  text(i:i) = chararray (i)
end do
print *, ">", text, "<"
  end function chararray2string
end program TestStringTools

% gfc auto_char_len_3_db_1.f90 -m32
% ./a.out
 >AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz<

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

[Bug libstdc++/84928] New: std::accumulate should move the accumulator argument

[jens.auer-gcc at betaversion dot net]

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

Bug ID: 84928
   Summary: std::accumulate should move the accumulator argument
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.auer-gcc at betaversion dot net
  Target Milestone: ---

std::accumulate is currently defined as

   template
 inline _Tp
 accumulate(_InputIterator __first, _InputIterator __last, _Tp __init)
 {
   // concept requirements
   __glibcxx_function_requires(_InputIteratorConcept<_InputIterator>)
   __glibcxx_requires_valid_range(__first, __last);

   for (; __first != __last; ++__first)
 __init = __init + *__first;
   return __init;
  }

   template
 inline _Tp
 accumulate(_InputIterator __first, _InputIterator __last, _Tp __init,
_BinaryOperation __binary_op)
 {
   // concept requirements
   __glibcxx_function_requires(_InputIteratorConcept<_InputIterator>)
   __glibcxx_requires_valid_range(__first, __last);

   for (; __first != __last; ++__first)
 __init = __binary_op(__init, *__first);
   return __init;
  }

The accumulator argument should be moved to reduce unnecessary copies of when
passed to the binary operation or operator+:

29.8.2.2
... acc = std::move(acc) + *i or acc = binary_op(std::move(acc), *i) ...

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[w.clodius at icloud dot com]

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

--- Comment #2 from William Clodius  ---
FWIW I get the same misleading message for other variants of illegal code.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #18 from Zhendong Su  ---
> and attach small.tar.bz2, that will contain all the dumps.

Jakub, done; please take a look.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #17 from Zhendong Su  ---
Created attachment 43694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43694=edit
output from "gcctk -O3 -S -fdump-tree-all small.c"

[Bug c++/84927] New: [7/8 Regressiion] ICE with NSDMI and reference

[reichelt at gcc dot gnu.org]

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

Bug ID: 84927
   Summary: [7/8 Regressiion] ICE with NSDMI and reference
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet triggers an ICE since GCC 7.1.0:

==
struct A
{
  int& r;
  int i = r;
};

void foo()
{
  int j;
  A a = A{j};
}
==

bug.cc: In function 'void foo()':
bug.cc:16:12: internal compiler error: non-constant element in constant
CONSTRUCTOR
   A a = A{j};
^
0x11445b0 verify_constructor_flags(tree_node*)
../../gcc/gcc/tree.c:1987
0x8578e7 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4535
0x8584d2 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4697
0x857057 cxx_eval_indirect_ref
../../gcc/gcc/cp/constexpr.c:3329
0x857057 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4334
0x858716 cxx_eval_component_reference
../../gcc/gcc/cp/constexpr.c:2494
0x858716 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4494
0x858831 cxx_eval_indirect_ref
../../gcc/gcc/cp/constexpr.c:3285
0x858831 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4334
0x857b03 cxx_eval_bare_aggregate
../../gcc/gcc/cp/constexpr.c:2845
0x857b03 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4541
0x85bee7 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4835
0x85eb96 maybe_constant_value(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:5053
0x86e4c1 cp_fully_fold(tree_node*)
../../gcc/gcc/cp/cp-gimplify.c:2071
0x9f3526 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/gcc/cp/typeck2.c:848
0x88718a check_initializer
../../gcc/gcc/cp/decl.c:6467
0x89f38c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:7121
0x93b893 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19723
0x942cc8 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13057
0x943ad8 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12882
Please submit a full bug report, [etc.]

Strict aliasing-related bug even with optimizations disabled

[Jonathon Reinhart]

This was originally posted on Stack Overflow:
https://stackoverflow.com/a/49339771/119527

The following program:

#include 

static void pshort(short val)
{
   printf("0x%hx ", val);
}

int main(void)
{
   short A[] = {1, 2, 3, 4, 5, 6};

#define EXP ((short*)((char*)A + 7))

   short *p = EXP;
   short q = *EXP;

   pshort(*p);
   pshort(q);
   pshort(*EXP);
   printf("\n");

   return 0;
}

...when compiled on x86-64 with

gcc -O0 -fno-strict-aliasing -g -Wall -Werror endian.c

...produces the following unexpected output

0x500 0x500 0x4

...on all available versions of GCC, from 4.9 thru 7.3.1.

It appears that GCC is actually generating different code when the
expression is used directly as an argument, versus when used with
intermediate variables.

The language lawyers declared that UB is UB. But -fno-strict-aliasing
seems to be ineffective here, and this feels like a bug.

Jonathon Reinhart

[Bug c++/79937] [6/7 Regression] ICE in replace_placeholders_r

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE in   |[6/7 Regression] ICE in
   |replace_placeholders_r  |replace_placeholders_r

--- Comment #23 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug lto/84926] New: error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64

[dilyan.palauzov at aegee dot org]

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

Bug ID: 84926
   Summary: error: inlining failed in call to always_inline
‘_mm_crc32_u64’: target specific option mismatch
_mm_crc32_u64
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

With the most current code of git://git.postgresql.org/git/postgresql.git,
branch REL_10_STABLE, doing

make maintainer-clean -j4; PYTHON=/usr/local/bin/python3.6 ./configure
--prefix=/usr/local --with-perl --with-tcl --with-gssapi --with-ldap
--with-openssl --with-libxml --with-libxslt --with-systemd --with-python
--enable-cassert
make CFLAGS="-flto"

fails with

make -C src all
make[1]: Entering directory '/git/postgresql/src'
make -C common all
make[2]: Entering directory '/git/postgresql/src/common'
make -C ../backend submake-errcodes
make[3]: Entering directory '/git/postgresql/src/backend'
make[3]: Nothing to be done for 'submake-errcodes'.
make[3]: Leaving directory '/git/postgresql/src/backend'
make[2]: Leaving directory '/git/postgresql/src/common'
make -C port all
make[2]: Entering directory '/git/postgresql/src/port'
make -C ../backend submake-errcodes
make[3]: Entering directory '/git/postgresql/src/backend'
make[3]: Nothing to be done for 'submake-errcodes'.
make[3]: Leaving directory '/git/postgresql/src/backend'
gcc -flto -I../../src/port -DFRONTEND -I../../src/include  -D_GNU_SOURCE
-I/usr/local/include/libxml2   -c -o pg_crc32c_sse42.o pg_crc32c_sse42.c
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0,
 from pg_crc32c_sse42.c:19:
pg_crc32c_sse42.c: In function ‘pg_comp_crc32c_sse42’:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:846:1: error:
inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific
option mismatch
 _mm_crc32_u64 (unsigned long long __C, unsigned long long __V)
 ^
pg_crc32c_sse42.c:37:18: note: called from here
   crc = (uint32) _mm_crc32_u64(crc, *((const uint64 *) p));
  ^
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0,
 from pg_crc32c_sse42.c:19:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:839:1: error:
inlining failed in call to always_inline ‘_mm_crc32_u32’: target specific
option mismatch
 _mm_crc32_u32 (unsigned int __C, unsigned int __V)
 ^
pg_crc32c_sse42.c:44:7: note: called from here
   crc = _mm_crc32_u32(crc, *((const unsigned int *) p));
   ^
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0,
 from pg_crc32c_sse42.c:19:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:827:1: error:
inlining failed in call to always_inline ‘_mm_crc32_u8’: target specific option
mismatch
 _mm_crc32_u8 (unsigned int __C, unsigned char __V)
 ^~~~
pg_crc32c_sse42.c:63:7: note: called from here
   crc = _mm_crc32_u8(crc, *p);
   ^~~
make[2]: *** [: pg_crc32c_sse42.o] Error 1
make[2]: Leaving directory '/git/postgresql/src/port'
make[1]: *** [Makefile:38: all-port-recurse] Error 2
make[1]: Leaving directory '/git/postgresql/src'
make: *** [GNUmakefile:11: all-src-recurse] Error 2

without -flto it works.  I use gcc 7.3.1 20180316.

With gcc 6.4.1 20180308 it also worked.  I don't think this is relevant, but
after switching 6->7 I have updated
/usr/local/lib/bfd-plugin/liblto_plugin.so.0.0.0 to point to the new location.

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #1 from Harald Anlauf  ---
NAG, Intel and Sunf95 reject the code with a duplicate symbol error.

After removing the 'module' before subroutine and some cleanup, NAG prints:

NAG Fortran Compiler Release 6.1(Tozai) Build 6106
Error: pr84922.f90, line 14: Duplicate subprogram name COPY_BYTE_DATA
   detected at SUBROUTINE@COPY_BYTE_DATA

So probably gfortran just produces a misleading error message...

[Bug fortran/84924] Erroneous error in C_F_POINTER

[johnsonsr at ornl dot gov]

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

--- Comment #3 from Seth Johnson  ---
That's correct, because those standards include TS 29113 which allows arrays to
be referenced. `-std=f2008ts` also works. The problem is that the usage
described is valid Fortran 2003 but is marked otherwise.

This is like the "const" qualifier raising an error with `gcc -std=c89` but
allowing it with `gcc -std=c99`. It's valid with C99, sure, but the feature is
allowed in the C89 standard as well.

[Bug fortran/84924] Erroneous error in C_F_POINTER

[anlauf at gmx dot de]

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

--- Comment #2 from Harald Anlauf  ---
There is no error for -std=f2008ts or -std=2018.

[Bug c++/84925] [8 Regression] ICE with segfault in __PRETTY_FUNCTION__

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -12898,7 +12898,7 @@ enclosing_instantiation_of (tree otctx)
   for (; flambda_count < lambda_count && fn && LAMBDA_FUNCTION_P (fn);
   fn = decl_function_context (fn))
++flambda_count;
-  if (DECL_TEMPLATE_INFO (fn)
+  if ((fn && DECL_TEMPLATE_INFO (fn))
  ? most_general_template (fn) != most_general_template (tctx)
  : fn != tctx)
continue;

seems to DTRT.

[Bug c++/84925] [8 Regression] ICE with segfault in __PRETTY_FUNCTION__

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
template 
struct A {
  static const int value = 0;
  static auto constexpr fn = [] { return __PRETTY_FUNCTION__; };
};
template 
int x = A::value;
auto s = x;

[Bug c++/84925] [8 Regression] ICE with segfault in __PRETTY_FUNCTION__

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Started with r251567.

[Bug c++/84925] [8 Regression] ICE with segfault in __PRETTY_FUNCTION__

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-17
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|ICE with segfault in|[8 Regression] ICE with
   |__PRETTY_FUNCTION__ |segfault in
   |(regression over gcc-7) |__PRETTY_FUNCTION__
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.

[Bug c++/84925] ICE with segfault in __PRETTY_FUNCTION__ (regression over gcc-7)

[h2+bugs at fsfe dot org]

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

--- Comment #1 from Hannes Hauswedell  ---
Created attachment 43693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43693=edit
intermediate file from crash

[Bug c++/84925] New: ICE with segfault in __PRETTY_FUNCTION__ (regression over gcc-7)

[h2+bugs at fsfe dot org]

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

Bug ID: 84925
   Summary: ICE with segfault in __PRETTY_FUNCTION__ (regression
over gcc-7)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

Created attachment 43692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43692=edit
code that crashes gcc-8

I have attached a test.cpp

g++-7 (Debian 7.3.0-8) builds this fine.
g++-8 (Debian 8-20180308-1) segfaults on this with

test.cpp:537:25: internal compiler error: Speicherzugriffsfehler
 auto name_ptr = __PRETTY_FUNCTION__;

I have also attached an intermediate file.

Thanks for your help!

[Bug fortran/84924] Erroneous error in C_F_POINTER

[johnsonsr at ornl dot gov]

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

--- Comment #1 from Seth Johnson  ---
- Correction in test case: `call dellocate(` should be replaced by
`deallocate(` (but this doesn't affect the behavior or test outcome
- Also note that the Fortran 2003 standard itself includes a structurally
identical example in "C.10.2.4 Example of opaque communication between C and
Fortran", if further evidence is needed that this is allowable with
`-std=f2003` and `-std=f2008`.

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

[dominiq at lps dot ens.fr]

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

--- Comment #22 from Dominique d'Humieres  ---
For the original test

   program p
  character :: z = 'z'
  print *, repeat(z, huge(1_4))
   end

I get

% gfc pr66310.f90 -m32
% ./a.out > zzz
a.out(22882,0xa9b3c1c0) malloc: *** mach_vm_map(size=2147483648) failed (error
code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

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

[Bug fortran/84924] New: Erroneous error in C_F_POINTER

[johnsonsr at ornl dot gov]

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

Bug ID: 84924
   Summary: Erroneous error in C_F_POINTER
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johnsonsr at ornl dot gov
  Target Milestone: ---

Created attachment 43691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43691=edit
Module exemplifying failure

The gfortran compiler mistakenly prohibits calls to `c_f_pointer` where `fptr`
is a noninteroperable *scalar* derived type. The standard only prohibits this
for *arrays* of the derived type (and this restriction is lifted in TS29113).

The compiler correctly allows `c_loc(fptr)` on the same pointer object; and
according to the standard the ability to do `c_loc` and `c_f_pointer` should be
symmetric.

I have attached a minimal test case:
```
$ gfortran-mp-7 -save-temps -std=f2003 -c -Wall -Wextra ftest.f90
ftest.f90:27:38:

 call c_f_pointer(cptr=p, fptr=handle)
  1
Error: TS 29113/TS 18508: Noninteroperable array FPTR at (1) to C_F_POINTER:
Expression is a noninteroperable derived type
```

I think the code in `gfc_check_c_f_pointer` in `gcc/fortran/check.c` simply
needs to be replaced by similar code in `gfc_check_c_loc`:
```
if (!is_c_interoperable (fptr, , false, true))
```
should become
```
if (fptr->rank > 0 && !is_c_interoperable (fptr, , false, true))
```

[Bug fortran/82992] ICE in create_int_parameter_array, at fortran/module.c:6586

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
The accepts-invalid also happens for the simpler examples:

subroutine sub (c_int)
   use iso_c_binding, only: c_int
end

The NAG compiler complains:

NAG Fortran Compiler Release 6.1(Tozai) Build 6106
Error: pr82992b.f90, line 2: Name clash between dummy argument C_INT and symbol
from USE ISO_C_BINDING
   detected at C_INT@
Warning: pr82992b.f90, line 3: Unused dummy variable C_INT
[NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning]


or for a simple, non-intrinsic module:

module pr82992
  integer :: x
end module pr82992
subroutine sub (x)
  use pr82992
end


Error: pr82992c.f90, line 5: Name clash between dummy argument X and symbol
from USE PR82992
   detected at PR82992@
Warning: pr82992c.f90, line 6: Unused dummy variable X
[NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning]

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

[anlauf at gmx dot de]

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

--- Comment #21 from Harald Anlauf  ---
(In reply to Jerry DeLisle from comment #20)
>program p
>   character(kind=1), parameter :: z = 'z'
>   integer, parameter :: big = 536870911
>   !print *, repeat(z, huge(1_4)/4)
>   !print *, (huge(1)-1)/4, huge(1) - 1
>   print *, repeat(z, big)
>end

Works for me on i686-pc-linux-gnu.

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #6)
> On the other side, the warning matches the documented behavior and it might
> be too difficult to add all the exceptions when we know that the argument
> will not be really dereferenced.

How many exceptions are there, beside %p?

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
On the other side, the warning matches the documented behavior and it might be
too difficult to add all the exceptions when we know that the argument will not
be really dereferenced.

[Bug c++/67796] Definition for custom std::swap found by ADL but not used

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Closing due to lack of feedback.

[Bug target/84072] [meta-bug] -mindirect-branch=thunk issues

[hjl.tools at gmail dot com]

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

Bug 84530 Summary: -mfunction-return=thunk does not work for 
simple_return_pop_internal insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84530

   What|Removed |Added

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

[Bug c++/84918] Better handling of "std::cout >> 42;"

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This seems pretty low priority though, there's a lot of output, but all of it
tells you the problem:

42.cc:4:18: note:   ‘std::ostream {aka std::basic_ostream}’ is not
derived from ‘std::basic_istream<_CharT, _Traits>’
 std::cout >> 42;
  ^~

I'd much rather see a solution to the more general problem of drowning the user
in information when the overload set is very large. That happens with many
operators, but especially << and >>. A special case to reduce that just for the
trivial typo of using >> when you mean << doesn't help the common case.

See PR 58713 comment 6 and 7

[Bug target/84530] -mfunction-return=thunk does not work for simple_return_pop_internal insn

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
Fixed for GCC 8.

[Bug target/84574] Function return thunks shouldn't be aliased to indirect branch thunks

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #2 from H.J. Lu  ---
Fixed.

[Bug target/84072] [meta-bug] -mindirect-branch=thunk issues

[hjl.tools at gmail dot com]

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

Bug 84574 Summary: Function return thunks shouldn't be aliased to indirect 
branch thunks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84574

   What|Removed |Added

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

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Yeah, only arguments corresponding to %s/%ls/%S/%n or whatever else can
actually dereference the pointer (for *scanf of course all the pointers).

[Bug c++/71965] [6/7/8 regression] [concepts] Substitution error *after* failure to satisfy an earlier constraint

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #8 from Alexandre Oliva  ---
Patch posted, unchanged.
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00836.html

[Bug c++/71251] [6/7/8 regression] ICE on invalid code, with unusual template name

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #7 from Alexandre Oliva  ---
Patch posted, unchanged.
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00837.html

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
The first dump is some gimple dump (*.*t.*, so not cse dump, and the latter one
is without optimizations, I thought you get the ICE only with -O3.
Just do:
rm -rf small.c.*
gcctk -O3 -S -fdump-tree-all small.c
tar cjf small.tar.bz2 small.c*
and attach small.tar.bz2, that will contain all the dumps.

[Bug tree-optimization/84921] [5 Regression] With -O3 gcc incorrectly assumes aligned SSE instructions (e.g. movdqa) can be used

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
GCC 5.x is not supported anymore.

[Bug target/84902] [8 Regression] 549.fotonik3d_r from SPEC2017 fails verification with -Ofast -march=native on Zen since r258518

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Sat Mar 17 11:12:00 2018
New Revision: 258618

URL: https://gcc.gnu.org/viewcvs?rev=258618=gcc=rev
Log:
PR target/84902
* config/i386/i386.c (initial_ix86_tune_features,
initial_ix86_arch_features): Use unsigned HOST_WIDE_INT rather than
unsigned long long.
(set_ix86_tune_features): Change ix86_tune_mask from unsigned int
to unsigned HOST_WIDE_INT, initialize to HOST_WIDE_INT_1U << ix86_tune
rather than 1u << ix86_tune.  Formatting fix.
(ix86_option_override_internal): Change ix86_arch_mask from
unsigned int to unsigned HOST_WIDE_INT, initialize to
HOST_WIDE_INT_1U << ix86_arch rather than 1u << ix86_arch.
(ix86_function_specific_restore): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug fortran/84615] [8 Regression] Executable Segfault for some tests compiled with -m32 after r256284

[jb at gcc dot gnu.org]

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

--- Comment #9 from Janne Blomqvist  ---
(In reply to Dominique d'Humieres from comment #8)
> Another test that does not require -fdefault-integer-8
> 
> module chtest
> contains
>   function chararray2string(chararray) result(text)
> character(len=1), dimension(:) :: chararray! input
> character(len=int(size(chararray, 1), kind=8)) :: text  ! output
> print *, ">", chararray, "<"
> do i = 1,size(chararray,1)
>   text(i:i) = chararray (i)
> end do
> print *, ">", text, "<"
>   end function chararray2string
> end module chtest
> program TestStringTools
>   use chtest
>   character(len=52)   :: txt
>   character(len=1), dimension(52) :: chararr = &
> (/(char(i+64),char(i+96), i = 1,26)/)
>   print *, ">", chararr, "<"
>   txt = chararray2string(chararr)
>   if (txt .ne. "AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz") &
> STOP 1
> end program TestStringTools

I think I see what the problem is, though I don't yet know how to fix it.
Looking at the tree-dump-original (compiled on i686) we have the function
chararray2string:

chararray2string (character(kind=1)[1:..__result] & __result, integer(kind=4)
.__result, ...

i.e. the charlen type is integer(4) (gfc_charlen_type_node in the frontend) as
it should be, although in the source the length is declared as an integer(8).
This is the correct thing to do, as we cannot know what the charlen kind of a
function is. Thus we must always, regardless of how it's declared, convert it
to gfc_charlen_type_node.

However, when looking at how that function is called, it uses an integer(8)
variable for the charlen. This is clearly wrong. Looking at the .mod file we
have

(2 'chararray2string' 'chtest' '' 1 ((PROCEDURE UNKNOWN-INTENT
MODULE-PROC DECL UNKNOWN 0 0 FUNCTION ALWAYS_EXPLICIT) () (CHARACTER 1 0
0 0 CHARACTER ((FUNCTION (INTEGER 8 0 0 0 INTEGER ()) 0 3 (('' (
FUNCTION (INTEGER 4 0 0 0 INTEGER ()) 0 4 (('' (VARIABLE (CHARACTER 1 0
0 0 CHARACTER ((CONSTANT (INTEGER 4 0 0 0 INTEGER ()) 0 '1' ( 1 5 (
(ARRAY (FULL 1 2))) ())) ('' (CONSTANT (INTEGER 4 0 0 0 INTEGER ()) 0 '1'
())) ('' ())) '' 0 'size' ())) ('kind' (CONSTANT (INTEGER 4 0 0 0
INTEGER ()) 0 '8' ( '__int_8_i4' 0 'int' ( 6 0 (5) () 7 () () ()
0 0)


That is, if I'm reading this correctly, the type of the charlen of the return
value is "FUNCTION (INTEGER 8...".  


I suspect this is the same reason for all those regressions with
"-fdefault-integer-8 -m32".

[Bug c++/71965] [6/7/8 regression] [concepts] Substitution error *after* failure to satisfy an earlier constraint

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #7 from Alexandre Oliva  ---
Created attachment 43690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43690=edit
candidate patch

Here's a work-around I'm testing.  It doesn't fix the underlying problem, just
the symptom.  The underlying problem will require some far more significant
revamping of concepts parsing, tsubsting, normalization, and evaluation than
I'd feel comfortable proposing at this point.

[Bug c/84923] New: gcc.dg/attr-weakref-1.c failed on aarch64

[vladimir.mezentsev at oracle dot com]

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

Bug ID: 84923
   Summary: gcc.dg/attr-weakref-1.c failed on aarch64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.mezentsev at oracle dot com
  Target Milestone: ---

ramana.radhakrish...@arm.com implemented (2015-11-06, commit
cd4fcdb8ff16ec2dad56f9e736ac4552f8f52001)
a new feature ('Switch constant pools to separate rodata sections').
An additional fix is needed for this feature.

The test below demonstrates problem:
% cat t.c
extern void abort(void);
typedef int vtype;
static vtype Wv12 __attribute__((weakref ("wv12")));
extern vtype wv12 __attribute__((weak));

#define chk(p) do { if (!p) abort (); } while (0)

int main () {
  chk (!);
  chk (!);
  return (0);
}

% gcc  t.c
/tmp/cciZgRxK.o:(.rodata+0x0): undefined reference to `wv12'
/tmp/cciZgRxK.o:(.rodata+0x8): undefined reference to `wv12'

% gcc  t.c -S
% cat t.s

.size   main, .-main
.weakrefWv12,wv12   <<   Not here. This should be after
definitions of Wv12 and wv12.
Wv12.section.rodata
.align  3
.LC0:
.xword  Wv12
.align  3
.LC1:
.xword  wv12


It is a regression after fixing PR68256.
We can temporary restore Ramana's workaround in 
aarch64_use_blocks_for_constant_p to avoid this regression:
% git diff gcc/config/aarch64/aarch64.c 
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 4b5183b..222ea33 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -7735,7 +7735,11 @@ aarch64_use_blocks_for_constant_p (machine_mode,
const_rtx)
 {
   /* We can't use blocks for constants when we're using a per-function
  constant pool.  */
-  return !aarch64_can_use_per_function_literal_pools_p ();
+  /* Fixme::
+ return !aarch64_can_use_per_function_literal_pools_p ();
+ This return statement breaks gcc.dg/attr-weakref-1.c test.
+ For now we workaround this by returning false here.  */
+  return false;
 }

[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

--- Comment #20 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #19)
> > Can this be closed.
> 
> The problem is not fixed in 32-bit mode.

Dominique, what are you seeing? This is working fine with my system with -m32.

   program p
  character(kind=1), parameter :: z = 'z'
  integer, parameter :: big = 536870911
  !print *, repeat(z, huge(1_4)/4)
  !print *, (huge(1)-1)/4, huge(1) - 1
  print *, repeat(z, big)
   end

[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3

[b7.10110111 at gmail dot com]

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

--- Comment #5 from Ruslan  ---
Yes, this is exactly the problem: the generic case is optimized while the
special case, where the divisor is a compile-time constant, isn't.

[Bug c++/71251] [6/7/8 regression] ICE on invalid code, with unusual template name

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #6 from Alexandre Oliva  ---
Created attachment 43689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43689=edit
candidate patch

Mine.  Here's the patch I'm testing.