[Bug c++/68001] New: [cilkplus] ICE in cp_gimplify_expr, at cp/cp-gimplify.c:760

[ryan.burn at gmail dot com]

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

Bug ID: 68001
   Summary: [cilkplus] ICE in cp_gimplify_expr, at
cp/cp-gimplify.c:760
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below code causes the following ICE

rnburn@localhost ~/test/gcc_cilk $ c++17 -fcilkplus -lcilkrts t.cpp 
t.cpp: In function ‘void compute_cilk()’:
t.cpp:21:33: error: ‘do_not_optimize_away’ was not declared in this scope
   do_not_optimize_away(v1.data());
 ^
cc1plus: error: invalid use of ‘_Cilk_spawn’
t.cpp:18:26: error: invalid use of ‘_Cilk_spawn’
   auto v1 = cilk_spawn f();
  ^
t.cpp:18:26: internal compiler error: tree check: expected call_expr or
aggr_init_expr, have target_expr in cp_gimplify_expr, at cp/cp-gimplify.c:760
0xf2508c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9512
0x7fc015 tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
../../gcc/gcc/tree.h:2877
0x7fc015 cp_gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**)
../../gcc/gcc/cp/cp-gimplify.c:760
0xa965c2 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8025
0xaa80b1 gimplify_addr_expr
../../gcc/gcc/gimplify.c:4985
0xa97f09 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8162
0xaa386b gimplify_call_expr
../../gcc/gcc/gimplify.c:2452
0xa97dda gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8087
0xa9bb96 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5526
0xa97e58 gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:5302
0xa97e58 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8479
0xa9bb96 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5526
0xa993bb gimplify_statement_list
../../gcc/gcc/gimplify.c:1462
0xa993bb gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8531
0xa9bb96 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5526
0xa99209 gimplify_and_add(tree_node*, gimple_statement_base**)
../../gcc/gcc/gimplify.c:398
0xa99209 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8453
0xa9bb96 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5526
0xa993bb gimplify_statement_list
../../gcc/gcc/gimplify.c:1462
0xa993bb gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8531
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

//
#include   
#include   
#include
#include
#include 

const int N = 100'000'000;  

auto f() {  
  std::vector v(N); 
  auto rng = std::mt19937{std::random_device{}()};  
  std::uniform_real_distribution dist(0, 1);
  for (int i = 0; i < N; ++i) v[i] = std::log(std::sqrt(dist(rng)));
  return v; 
}   

void compute_cilk() {   
  auto v1 = cilk_spawn f(); 
  auto v2 = f();
  cilk_sync;
  do_not_optimize_away(v1.data());  
  do_not_optimize_away(v2.data()

[Bug tree-optimization/67998] redundant test for 0 when also checking inequality

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-17
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
Indeed. We might want to be careful about the case:

unsigned b = long_computation_without_side_effects();
if(!a || b>=a) ...

where it might be better to sink the computation if a is often 0:
if(!a) ...
else {
  unsigned b = long_computation_without_side_effects();
  if(b>=a) ...
}

(or maybe we can just ignore it)

[Bug c/67999] Wrong optimization of pointer comparisons

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
I don't think gcc supports using more than half the address space in a single
allocation. At least I've seen reports of bugs in the past, and I seem to
remember people not being very concerned...

[Bug c/67999] Wrong optimization of pointer comparisons

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
ssize_t is a signed integer and in the case of x86, it is 32bits which means
exactly what Marc wrote.

[Bug middle-end/68000] Suboptimal ternary operator codegen

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Independently of hoisting,

mov   eax, edx
add   edx, 1
add   eax, 1

apparently we fail to CSE this because at the time of CSE, one addition is done
in mode QI and the other in SI, and it is only in split2 that the QI one is
promoted to SI, which is too late for CSE.


Actually, it is quite hard to notice that foo is equivalent to the other
versions. If you wrote: return (uint8_t)(p->x + 1) == p->y ? 0 : p->x + 1; it
would be much easier, and indeed I get better code. For the equivalence, the
compiler has to notice that the only case where the cast matters is when x is
255 and y is 0, and in that case both branches (after sinking the cast to
uint8_t from the return type) are equivalent.

[Bug c/67999] Wrong optimization of pointer comparisons

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  ---
Did you mean ptrdiff_t?

[Bug fortran/67177] MOVE_ALLOC not automatically allocating deferred character arrays in derived types

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #2 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed for 5.2 and trunk (6.0). Note that it is in general better to post
> the non working test rather the working one.

The hidden component ._text_length is not being set by MOVE_ALLOC. The move of
the allocation is occurring correctly, however.

I am wading into move_alloc right now to fix the bug reported on clf by Alberto
Luaces: https://groups.google.com/forum/#!topic/comp.lang.fortran/k3bkKUbOpFU

I'll take a swing at this bug this afternoon. Right now I have to paint
shutters :-(

Paul

[Bug tree-optimization/67908] gcc segfaults with -fstack-check (internal compiler error) / armv7 host and target

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Thanks, it's already fixed on the branch.

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

[Bug tree-optimization/67055] [5 Regression] Segmentation fault in fold_builtin_alloca_with_align in tree-ssa-ccp.c

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||gcc-bugs at zahlenfresser dot 
de

--- Comment #18 from Eric Botcazou  ---
*** Bug 67908 has been marked as a duplicate of this bug. ***

[Bug middle-end/68002] New: retaining unused static functions at -O1

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 68002
   Summary: retaining unused static functions at -O1
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

There are uses for retaining unused static functions even if optimising, e.g.
coverage testing. Right now these function are removed at -O1 and there is no
flag to keep them. 

In https://gcc.gnu.org/ml/gcc-help/2015-10/msg00110.html Marc Glisse suggested
to introduce a flag similar to -fkeep-inline-functions.

c testcase:
> cat test.c
static void foo() { }

> gcc -c -O0 test.c ; nm test.o
 t foo
> gcc -c -O1 test.c ; nm test.o

Fortran testcase:

> cat test.f90
MODULE foo
 PRIVATE
CONTAINS
 SUBROUTINE bar()
 END SUBROUTINE bar
END MODULE

I'll try to come up with a patch based on Marc's suggestion

[Bug c/67999] Wrong optimization of pointer comparisons

[ch3root at openwall dot com]

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

--- Comment #4 from Alexander Cherepanov  ---
Interesting. In particular, this means that the warning "Argument 'size' of
function malloc has a fishy (possibly negative) value" from valgrind is a
serious thing. Is this gcc limitation documented somewhere? Is there a better
reference than this bug?

Am I right that the C standards do not allow for such a limitation (and hence
this should not be reported to glibc as a bug) and gcc is not
standards-compliant in this regard? Or I'm missing something?

[Bug target/67994] __attribute__ ((target("arch=XXX"))) enables unsupported ISA

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
dup

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

[Bug target/67995] __attribute__ ((target("arch=XXX"))) enables unsupported ISA

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
*** Bug 67994 has been marked as a duplicate of this bug. ***

[Bug c++/68003] New: Variable declared in condition in for loop is destroyed too soon

[gcc-bugzilla at contacts dot eelis.net]

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

Bug ID: 68003
   Summary: Variable declared in condition in for loop is
destroyed too soon
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at contacts dot eelis.net
  Target Milestone: ---

Consider:

  #include 
  #include 

  struct X
  {
bool alive = true;
~X() { alive = false; }

explicit operator bool() const { return true; }
  } ;

  int main()
  {
for(int i = 0; X x = X(); assert(x.alive))
  if (++i == 3)
break;
  else
std::cout << i << std::endl;
  }

When compiled with gcc trunk, the program outputs:

  1
  a.out: t.cpp:14: int main(): Assertion `x.alive' failed.

When compiled with clang trunk, the program outputs:

  1
  2

[Bug libstdc++/67996] std::ios_base::seekdir raises -Wswitch with Clang

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Then maybe the warning needs to be smarter, e.g. not warn for enumerators
defined in system headers using the implementation's reserved names.

In any case, it's not a libstdc++ problem, our code is correct, and GCC doesn't
issue any warning.

[Bug fortran/67177] MOVE_ALLOC not automatically allocating deferred character arrays in derived types

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
(In reply to Paul Thomas from comment #2)
> (In reply to Dominique d'Humieres from comment #1)
> > Confirmed for 5.2 and trunk (6.0). Note that it is in general better to post
> > the non working test rather the working one.
> 
> The hidden component ._text_length is not being set by MOVE_ALLOC. The move
> of the allocation is occurring correctly, however.
> 
> I am wading into move_alloc right now to fix the bug reported on clf by
> Alberto Luaces:
> https://groups.google.com/forum/#!topic/comp.lang.fortran/k3bkKUbOpFU
> 
> I'll take a swing at this bug this afternoon. Right now I have to paint
> shutters :-(
> 
> Paul

In fact, the move_alloc part is one of two bugs exposed by this testcase.

The other bug is contained in:
! Needs blanking otherwise memory is leaked
tmpstr%text(1:20) = ' '
tmpstr%text(1:3) = 'foo'

and has been reported as PR67977. I'll fix this one as well, whilst I am about
it.

Cheers

Paul

[Bug c++/68003] Variable declared in condition in for loop is destroyed too soon

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-17
 Ever confirmed|0   |1

[Bug c++/51553] brace initialization and conversion operators

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Jason, is this resolution definitely correct? Clang and EDG agree with GCC 4.6
here, and [over.best.ics] does seem relevant.

Maybe related, maybe not. G++ also rejects:

struct A {
explicit operator bool() const { return false; }
};
A a;
bool b = bool{a};

which Clang and EDG accept, and it certainly seems odd when bool(a) and (bool)a
are OK.

[Bug middle-end/68002] retaining unused static functions at -O1

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2015-10/msg01667.ht
   ||ml
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #1 from Joost VandeVondele  
---
patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01667.html

[Bug fortran/67987] ICE on declaring and initializing character with negative len

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Oct 17 16:50:47 2015
New Revision: 228933

URL: https://gcc.gnu.org/viewcvs?rev=228933&root=gcc&view=rev
Log:
2015-10-17  Steven G. Kargl  

PR fortran/67987
* decl.c (char_len_param_value): Unwrap unlong line.  If LEN < 0,
force it to zero per the Fortran 90, 95, 2003, and 2008 Standards. 
* resolve.c (gfc_resolve_substring_charlen): Unwrap unlong line.
If 'start' is larger than 'end', length of substring is negative,
so explicitly set it to zero.
(resolve_charlen): Remove -Wsurprising warning.  Update comment to
reflect that the text is from the F2008 standard.

2015-10-17  Steven G. Kargl  

PR fortran/67987
* gfortran.df/pr67987.f90: New test.
* gfortran.dg/char_length_2.f90: Update testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr67987.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/char_length_2.f90

[Bug other/68004] New: mails from mail.ru blocked

[fedor_qd at mail dot ru]

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

Bug ID: 68004
   Summary: mails from mail.ru blocked
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fedor_qd at mail dot ru
  Target Milestone: ---

gcc-h...@gcc.gnu.org
    SMTP error from remote mail server after end of data:
    host gcc.gnu.org [209.132.180.131]: 552 spam score exceeded threshold

[Bug fortran/68005] New: internal compiler error with -O3 -g -fopenmp

[askhamwhat at gmail dot com]

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

Bug ID: 68005
   Summary: internal compiler error with -O3 -g -fopenmp
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: askhamwhat at gmail dot com
  Target Milestone: ---

Created attachment 36535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36535&action=edit
reproduces the compiler error with flags listed above

internal compiler error: output_operand: floating constant misused

This is the reported error for the attached example when compiled using:

gfortran -c -g -O3 -fopenmp mincode.f

All 3 flags are required to produce the error (also occurs with -O2 or -O1 but
not -O0)

Version details: GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)

[Bug fortran/68005] internal compiler error with -O3 -g -fopenmp

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-17
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Travis Askham from comment #0)
> Created attachment 36535 [details]
> reproduces the compiler error with flags listed above
> 
> internal compiler error: output_operand: floating constant misused
> 
> This is the reported error for the attached example when compiled using:
> 
> gfortran -c -g -O3 -fopenmp mincode.f
> 
> All 3 flags are required to produce the error (also occurs with -O2 or -O1
> but not -O0)
> 
> Version details: GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)

Your code compile with 4.8.5, 4.9.4, 5.2.1, and 6.0.0 with
the above options.  Please update your compiler to a 
much newer version.

[Bug c++/68006] New: [6 Regression] [C++14] Incorrect aggregate initialization from empty initializer list with NSDMI

[Casey at Carter dot net]

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

Bug ID: 68006
   Summary: [6 Regression] [C++14] Incorrect aggregate
initialization from empty initializer list with NSDMI
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

r228925 miscompiles this program:

inline void* operator new(decltype(sizeof(0)), void* ptr) {
  return ptr;
}

struct X { int x; int y; int z = 42; };

void test_bar(X* p) {
  new(p) X{};   // Bad.
}

to:

~/gcc6/bin/g++ -std=c++14 foo.cpp -O -S -o -
.file   "foo.cpp"
.text
.globl  _Z8test_barP1X
.type   _Z8test_barP1X, @function
_Z8test_barP1X:
.LFB1:
.cfi_startproc
movl$42, 8(%rdi)
ret
.cfi_endproc
.LFE1:
.size   _Z8test_barP1X, .-_Z8test_barP1X
.ident  "GCC: (GNU) 6.0.0 20151016 (experimental)"
.section.note.GNU-stack,"",@progbits

The construction in test_bar only initializes the member with the NSDMI - X::z
- and does not correctly initialize the other members to 0. GCC 5.1 and 5.2
both compile the program correctly:

~/gcc-5.2/bin/g++ -std=c++14 foo.cpp -O -S -o -
.file   "foo.cpp"
.text
.globl  _Z8test_barP1X
.type   _Z8test_barP1X, @function
_Z8test_barP1X:
.LFB1:
.cfi_startproc
movl$0, (%rdi)
movl$0, 4(%rdi)
movl$42, 8(%rdi)
ret
.cfi_endproc
.LFE1:
.size   _Z8test_barP1X, .-_Z8test_barP1X
.ident  "GCC: (GNU) 5.2.0"
.section.note.GNU-stack,"",@progbits

[Bug fortran/68005] internal compiler error with -O3 -g -fopenmp

[askhamwhat at gmail dot com]

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

--- Comment #2 from Travis Askham  ---
Newer versions work (I tried 4.8.4 on a personal machine). Will request an
update from my sysadmin...

Thanks.

[Bug other/68004] mails from mail.ru blocked

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #1 from Mikhail Maltsev  ---
Hi. Do I understand correctly, that you are were trying to post a message to
the gcc-help mailing list via mail.ru SMTP server and it got bounced?

See https://sourceware.org/lists.html#spam

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[wmi at google dot com]

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

--- Comment #12 from wmi at google dot com ---
Yes, I agree it is a problem that memrefs_conflict_p doesn't take effect. But I
am still wondering even if memrefs_conflict_p doesn't take effect, the alias
oracle query in rtx_refs_may_alias_p should have returned may-alias for the
load and store. Why rtx_refs_may_alias_p failed to do that?

[Bug c/68007] New: False warning for integer overflow for unsigned integers

[r.f.vannieuwpoort at student dot tudelft.nl]

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

Bug ID: 68007
   Summary: False warning for integer overflow for unsigned
integers
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: r.f.vannieuwpoort at student dot tudelft.nl
  Target Milestone: ---

The assignment of 0x7fff + 1 to a 32-bit unsigned integer causes a false
warning for an integer overflow (it would overflow if it was assigned to a
signed integer).

Example: uint32_t a = 0x7fff + 1

Compileable example:
#include 
int main(int argc, char *argv[])
{
uint32_t a = 0x7fff + 1;
return 0;
}

[Bug fortran/68005] internal compiler error with -O3 -g -fopenmp

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from kargl at gcc dot gnu.org ---
Travis, thanks for the follow-up.  I'm going to close this as fixed.

[Bug other/68004] mails from mail.ru blocked

[fedor_qd at mail dot ru]

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

--- Comment #2 from Fiodar  ---
(In reply to Mikhail Maltsev from comment #1)
> Hi. Do I understand correctly, that you are were trying to post a message to
> the gcc-help mailing list via mail.ru SMTP server and it got bounced?
> 
> See https://sourceware.org/lists.html#spam

You correctly understand. Thanks for link - problem solved

[Bug c/68007] False warning for integer overflow for unsigned integers

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
0x7fff is of type int, and 0x7fff + 1 will overflow a 32-bit int.

[Bug other/68004] mails from mail.ru blocked

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

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

--- Comment #3 from Mikhail Maltsev  ---
Closing as fixed then.

[Bug ada/25844] [4.9/5/6 regression] ICE on overloaded renames

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #16 from Alexandre Oliva  ---
Created attachment 36536
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36536&action=edit
Reduced testcase

Here's a reduced version of the testcase.  The problem seems to have to do with
the double vs single access for V, but oddly it doesn't occur if the initial
line, apparently unused, is removed.  The problem doesn't occur either if A is
not a private type, or if the packages are not subpackages of X, or if J is
removed from X.L, or if J and B are defined as non-generic packages.

When comparing D.F with F, Check_Conformance fails the test for equivalent
Directly_Designated_Type in Old_Formal_Base and New_Formal_base, so
Access_Type_Match is false (though AFAICT it should be true), but it is
Conforming_Types, called with these base types, that eventually crashes, as
Subtypes_Statically_Match gets an access to A in t1 and A in t2.  When it takes
the Directly_Designated_Type of the latter, it gets zero; predicates_match
passes it to get_rep_item, that calls first_rep_item and gets -1, that causes
nkind to crash.

Clearly we need some more smarts in handling this kind of situation, either
during generic substitution or when checking access types for conformance.

[Bug gcov-profile/67924] Gcov statistics branches error

[langjitianya886 at 126 dot com]

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

deng  changed:

   What|Removed |Added

   Severity|normal  |major

[Bug tree-optimization/67921] [6 Regression] "internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147" when using -fsanitize=undefined

[amker.cheng at gmail dot com]

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

bin.cheng  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com

--- Comment #5 from bin.cheng  ---
Hmm, maybe it's another issue exposed by the change.  I tried the case with x86
gcc, both r224020 and r224019 give the same ICE messages.