[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

[tetra2005 at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Yuri Gribov  ---
Fix has been approved
(https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606858.html), I hope
to merge it soon.

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

[tetra2005 at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Yuri Gribov  ---
Posted to gcc-patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601041.html

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

[tetra2005 at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Yuri Gribov  ---
Created attachment 53493
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53493=edit
Updated patch

Here is an updated patch which passes bootstrap-asan (I haven't run the
testsuite yet).

It results in only small 0.15% reduction of optimized checks (146062 ->
145824). But more importantly the complicated alias oracle check does not seem
to contribute anything - removing it from same_value_p function (the name is
ugly, I know) does not change the number of optimized checks. So I'm not sure
it makes sense to keep it in final patch.

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

[tetra2005 at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Yuri Gribov  ---
(In reply to Jakub Jelinek from comment #7)

I've started work on this but I'll probly only have enough time to cook a patch
on weekend.

> Perhaps either a quick check that for base ptrs that live in memory

A silly question, such cases (base_addrs living in memory) can be identified by
  gimple *g = SSA_NAME_DEF_STMT (t);
in maybe_get_single_definition having vuses?

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

[tetra2005 at gmail dot com via Gcc-bugs]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov  ---
Ok, seems my 2014 patch will need to be reverted then. Do you want me to submit
a PR?

[Bug libgomp/103276] New: [openacc] Trying to map already mapped data

[tetra2005 at gmail dot com via Gcc-bugs]

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

Bug ID: 103276
   Summary: [openacc] Trying to map already mapped data
   Product: gcc
   Version: og11 (devel/omp/gcc-11)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tetra2005 at gmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

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

I've ran into a duplicate mapping error with OpenACC which seems to be caused
by invalid handling of ENTER DATA pragma.

The pragma, when applied to a parameter of derived type, also maps some
spurious local variable to device memory. After the function exits, another one
is called and tries to map it's own local variables which causes aliasing
conflict due to overlapping memory ranges in libgomp splay tree structures:
  libgomp: Trying to map into device [0x7fffcf80..0x7fffcfd8) object
when [0x7fffcfc8..0x7fffcfd0) is already mapped

The assembly looks like
  leaq  8(%rsp), %rax   # POINTER TO LOCAL STACK VAR
  ...
  subq  $8, %rsp
  movl  $2, %esi# mapnum
  movq  %rdi, 24(%rsp)  # hostaddrs[0] (OK)
  movl  $-1, %edi   # flags_m
  movq  %rax, 32(%rsp)  # hostaddrs[1] (POINTS TO LOCAL STACK VAR)
  xorl  %eax, %eax
  pushq $0
  leaq  32(%rsp), %rdx  # hostaddrs
  call  GOACC_enter_exit_data
Here hostaddrs[1] points to a spurious variable in current stack frame.

Gimple code seems to be correct
  voidD.27 copyin_simple (struct simple & restrict varD.3961)
  { 
struct .omp_data_t.1D.3962 D.3965;
...
# .MEM_4 = VDEF <.MEM_3>
D.3965.varD.3964 = 
but expanded RTL is not:
  ;; .omp_data_arr.2.var = 

  (insn 8 7 9 (parallel [
(set (reg:DI 84)
(plus:DI (reg/f:DI 77 virtual-stack-vars)
(const_int -24 [0xffe8])))
(clobber (reg:CC 17 flags))
]) "repro.f90":11:28 -1
 (nil))

  (insn 9 8 0 (set (mem/f/c:DI (plus:DI (reg/f:DI 77 virtual-stack-vars)
(const_int -8 [0xfff8])) [6 D.3965.varD.3964+0 S8
A64])
(reg:DI 84)) "repro.f90":11:28 -1
 (nil)) 

Reproduced with attached code on devel/omp/gcc-11 branch (commit f85ed2296,
2021 Nov 10) with
  gfortran -O2 -ffree-form -ffree-line-length-none -fopenacc
-foffload-options=-march=gfx908 -fdump-tree-all-all -fdump-rtl-all-all -S
repro.f90

[Bug middle-end/95550] [OpenACC] ICE in expand_oacc_for, at omp-expand.c:6075

[tetra2005 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Yuri Gribov  ---
The promised repro:
  SUBROUTINE FOO()  
INTEGER :: I
COMPLEX(8), ALLOCATABLE :: GWORK(:)
ALLOCATE(GWORK(512))
  !$ACC PARALLEL LOOP PRIVATE(GWORK)
DO I = 1,512
  GWORK(I) = 0
ENDDO
  END SUBROUTINE

[Bug fortran/93554] [9/10/11/12 Regression] ICE in expand_oacc_for, at omp-expand.c:6035 since r6-4364-ge4834818d22f5c66

[tetra2005 at gmail dot com via Gcc-bugs]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #7 from Yuri Gribov  ---
Is this related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95550 ?

[Bug middle-end/95550] [OpenACC] ICE in expand_oacc_for, at omp-expand.c:6075

[tetra2005 at gmail dot com via Gcc-bugs]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #1 from Yuri Gribov  ---
Also fails on simpler code (on master and devel/omp/gcc-11 branches):

  $ gfortran -ffree-form -ffree-line-length-none -O2 -fopenacc -c kernel.f90
  kernel.f90:10:34:

   10 | !$ACC PARALLEL LOOP PRIVATE(GWORK)
  |  ^
  internal compiler error: in expand_oacc_for, at omp-expand.c:7529
  0x62c8b7 expand_oacc_for
  /home/y.gribov/src/gcc-omp/gcc/omp-expand.c:7529
  0x1605139 expand_omp_for
  /home/y.gribov/src/gcc-omp/gcc/omp-expand.c:8081
  0x1605afa expand_omp
  /home/y.gribov/src/gcc-omp/gcc/omp-expand.c:10302
  0x16053c5 expand_omp
  /home/y.gribov/src/gcc-omp/gcc/omp-expand.c:10288
  0x16079dd execute_expand_omp
  /home/y.gribov/src/gcc-omp/gcc/omp-expand.c:10536

[Bug ipa/102310] [11/12 Regression] ICE in visit_ref_for_mod_analysis with OpenACC

[tetra2005 at gmail dot com via Gcc-bugs]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
Thanks a lot for the support.  A related question: which branch should I use
when working on OpenACC code: master, releases/gcc-11 or devel/omp/gcc-11?

[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150

[tetra2005 at gmail dot com]

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

--- Comment #9 from Yuri Gribov  ---
Thanks for commiting this. Review on gcc-patches went stale...

On Wed, May 23, 2018 at 8:41 AM, marxin at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822
>
> --- Comment #8 from Martin Liška  ---
> Author: marxin
> Date: Wed May 23 07:40:43 2018
> New Revision: 260566
>
> URL: https://gcc.gnu.org/viewcvs?rev=260566=gcc=rev
> Log:
> PR tree-optimization/85822
>
> Added:
> trunk/gcc/testsuite/c-c++-common/pr85822.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/tree-vrp.c
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150

[tetra2005 at gmail dot com]

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

--- Comment #6 from Yuri Gribov  ---
(In reply to Richard Biener from comment #5)
> Created attachment 44145 [details]
> patch I am testing
> 
> I am testing the attached.  Please check how negative values can be handled
> correctly or why exactly the handling was wrong.

I think just removing the hunk I mentioned should fix it (I'll test and post to
gcc-patches today hopefully).

[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150

[tetra2005 at gmail dot com]

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

--- Comment #3 from Yuri Gribov  ---
It seems these lines in is_masked_range_test should be removed:
  if (wi::neg_p (val, TYPE_SIGN (type)))
std::swap (*low, *high);
Sadly there were no tests which tested negative constants. I'll bootstrap and
send patch tomorrow (hope there's no urgency?).

[Bug tree-optimization/85822] [8/9 Regression] Maybe wrong code in VRP since r249150

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
Checking.

[Bug middle-end/59521] __builtin_expect not effective in switch

[tetra2005 at gmail dot com]

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

--- Comment #14 from Yuri Gribov  ---
Patch posted in https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01016.html

[Bug middle-end/54123] inline functions not optimized as well as static inline

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
This was fixed in r206723. Ok to close?

[Bug middle-end/81376] unnecessary cast before comparison

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
Thanks, will take this one too (maybe after PR57371 is finally accepted).

[Bug middle-end/59521] __builtin_expect not effective in switch

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

  Attachment #41737|0   |1
is obsolete||

--- Comment #13 from Yuri Gribov  ---
Created attachment 41770
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41770=edit
Yet another patch

Ok, this one works both for __builtin_expect and -fprofile-generate and
survives bootstrap on x64. I've modified switch decision tree creation to
select pivot value based on probabilities rather than number of values on left
and right (somewhat similar to ID3 algorithm for decision trees).

If patch looks fine in general, I'll add tests and submit for review.

[Bug middle-end/59521] __builtin_expect not effective in switch

[tetra2005 at gmail dot com]

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

--- Comment #10 from Yuri Gribov  ---
(In reply to Martin Liška from comment #9)
> The patch works for me for the described case, but does not for PGO, which
> should do the same based on real numbers:

Problem here is that we optimize only very_likely edges.  They requires 99.95%
probability whereas in your testcase we only get 90%.  Changing mods to "%
1" and "% 100" results in desired asm:

cmpl$1, %eax
je  .L3
cmpl$10, %eax
je  .L4
cmpl$100, %eax
je  .L5

> Just a small note, Honza's planning to rewrite switch expansion to happen on
> tree level. Maybe (hopefully) such transformations
> will be easier on tree level?

Thanks, that's important to consider.  I'll send patch for review and Cc him to
maybe comment.  Probly I'll just rebase when his work is in.

[Bug middle-end/59521] __builtin_expect not effective in switch

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

  Attachment #41698|0   |1
is obsolete||

--- Comment #8 from Yuri Gribov  ---
Created attachment 41737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41737=edit
New draft patch

How about this? I added edge attribute for builtin_expect and later used it in
emit_case_decision_tree to emit expected comparison prior to decision tree for
other case values.

With this patch GCC optimizes original example. If it's not too ugly I'll do
proper testing and send to gcc-patches.

[Bug middle-end/59521] __builtin_expect not effective in switch

[tetra2005 at gmail dot com]

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

--- Comment #7 from Yuri Gribov  ---
(In reply to Martin Liška from comment #5)
> Apart from that I added code that preserves
> that probability in combine_predictions_for_bb.

Yes, I did pretty much the same locally)

> But still there's a missing piece that will rearrange switch statement so
> that case 333 will be first:

Right, I'll take it from there then.

[Bug middle-end/41992] ICE on invalid dereferencing of void *

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
Fixed long ago, most probly in r172298. Could someone close?

[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()

[tetra2005 at gmail dot com]

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

--- Comment #7 from Yuri Gribov  ---
(In reply to Michael Thayer from comment #6)
> Yuri, my initial description should still apply, though I haven't tested
> this recently.  The follow-up comments were Maxim trying to help me with a
> work-around.

Michael, the core issue is in libasan which is developed in LLVM and then
pulled to GCC. Max mentioned there's already an upstream bugreport
(https://bugs.llvm.org//show_bug.cgi?id=27790). We typically close regressions
caused by upstream packages as RESOLVED MOVED.

[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code

[tetra2005 at gmail dot com]

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

--- Comment #7 from Yuri Gribov  ---
(In reply to Marc Glisse from comment #6)
> (In reply to Yuri Gribov from comment #5)
> > Well, as we all know there are a lot of missing optimizations in GCC :) I
> > think the real question is whether it's ever going to be fixed if there's no
> > standard API for this code pattern which we can recognize as builtin.
> > 
> > I believe the answer is "No". ATM GCC does not vectorize even the simplest
> > memcpy equivalent code:
> >   // gcc tmp.c -O3 -mtune=native -ftree-vectorize -o- -S
> >   void memcpy_(char * __restrict a, char * __restrict b, unsigned n) {
> > unsigned i;
> > for (i = 0; i < n; ++i)
> >   a[i] = b[i];
> >   }
> 
> Please look again. ldist turns this into a call to memcpy. And if you
> disable ldist, it does get vectorized.

Hm, I've just tried r249806 both with -ftree-loop-distribution and
-fno-tree-loop-distribution on top of flags above without any changes in
output. This may depend on revision/flags/machine, which ones did you use?

[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code

[tetra2005 at gmail dot com]

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

--- Comment #5 from Yuri Gribov  ---
(In reply to Marc Glisse from comment #4)
> (In reply to Yuri Gribov from comment #3)
> > As noted in comments, this is more about adding new API to Glibc than GCC
> > (they have corresponding
> > https://sourceware.org/bugzilla/show_bug.cgi?id=19920 about this). So can
> > this be closed?
> 
> I don't think so (at least not for that reason). Whatever glibc does, this
> is still a missed optimization in gcc.

Well, as we all know there are a lot of missing optimizations in GCC :) I think
the real question is whether it's ever going to be fixed if there's no standard
API for this code pattern which we can recognize as builtin.

I believe the answer is "No". ATM GCC does not vectorize even the simplest
memcpy equivalent code:
  // gcc tmp.c -O3 -mtune=native -ftree-vectorize -o- -S
  void memcpy_(char * __restrict a, char * __restrict b, unsigned n) {
unsigned i;
for (i = 0; i < n; ++i)
  a[i] = b[i];
  }
so I don't think it'll be able to recognize memcchr in reasonable timeframe.

Adding a std. function in Glibc and then treating it as std. builtin in GCC
would be straightforward and cost-effective solution but the ball is on Glibc
side and they didn't sound very positive.

Thoughts?

[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code

[tetra2005 at gmail dot com]

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

--- Comment #3 from Yuri Gribov  ---
As noted in comments, this is more about adding new API to Glibc than GCC (they
have corresponding https://sourceware.org/bugzilla/show_bug.cgi?id=19920 about
this). So can this be closed?

[Bug middle-end/55546] Static functions that are fully inlined can end up in the object file

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
This was fixed in r198821. Could someone close?

[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov  ---
(In reply to Michael Thayer from comment #3)
> Seems my mistake.  I think the ASAN library was still getting loaded
> dynamically.  Now I have the following problem, which I think means that
> code (constructors?) getting called before ASAN is initialised is getting
> hold of memory map areas which ASAN is hard-coded to use.  So probably no
> static ASAN for me.

Michael, to work on this we'd need a complete repro. Or if you are no longer
interested in this, please close as CANTREPRO or something like this.

[Bug sanitizer/78028] ASAN doesn't find memory leak

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov  ---
I was able to repro this in Ubuntu 14.04 with GCC 5.4.0 but not with GCC 6.2.0
(the latter successfully reports both leaks). Generated asm code is almost
identical so probly fixed with one of libasan merges since GCC5.

Ok to close?

[Bug sanitizer/61995] gcc 4.9.1 fails to compile with error in libsanitizer

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
This is probly a dup of bug 59068. Can it be closed as such?

[Bug sanitizer/60892] GCC (libsanitizer) fails to build with Linux 2.6.21 headers.

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
This is probly a dup of bug 59068. Can it be closed as such?

[Bug sanitizer/61771] Test failures in ASan testsuite on ARM Linux due to FP format mismatch between libasan and GCC.

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #10 from Yuri Gribov  ---
This should be fixed since r229111 (and 229115). Close?

[Bug sanitizer/63245] renderMemorySnippet shouldn't show more bytes than the underlying type

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #3 from Yuri Gribov  ---
This has been fixed in r215527. Close?

[Bug sanitizer/61693] [asan] is not intercepting aligned_alloc

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov  ---
Has been fixed in r215527. Close?

[Bug sanitizer/78654] ubsan can lead to excessive stack usage

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
Overhead seems to be intentional so perhaps close?

[Bug sanitizer/62307] -fsanitize=undefined doesn't pay attention to __attribute__((returns_nonnull))

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov  ---
Given that nonnull attribute is ignored on purpose, perhaps this should be
closed (as wontfix)?

[Bug sanitizer/55316] gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error "Unsupported arch"

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
Can this be closed as not-a-bug?

[Bug sanitizer/58841] std::bad_alloc not thrown with -fsanitize=address

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #1 from Yuri Gribov  ---
Upstream dup: https://github.com/google/sanitizers/issues/295 . I suggest to
close this bug and track it upstream instead.

[Bug middle-end/59521] __builtin_expect not effective in switch

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Yuri Gribov  ---
Cc Martin to comment, as he added the problematic part in
combine_predictions_for_bb.

[Bug middle-end/59521] __builtin_expect not effective in switch

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
Created attachment 41698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41698=edit
Draft patch (not working)

This can be added easily but I ran into a block in combine_predictions_for_bb
which resets predictions whenever block has more than one outgoing edge and
predictor is not strong enough (like e.g. noreturn predictor).

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #11 from Yuri Gribov  ---
Note that this is a dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67165

[Bug other/67165] please enable libbacktrace to work with compressed debug sections

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
Patch under review here:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01868.html

[Bug tree-optimization/57371] Simplify (double)i != 0

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
Posted patch for review:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00034.html

[Bug ipa/80565] [8 Regression] ICE at -O2 and -O3 in 32-bit mode (not 64-bit) on x86_64-linux-gnu (in edge_badness, at ipa-inline.c:1028)

[tetra2005 at gmail dot com]

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

--- Comment #8 from Yuri Gribov  ---
(In reply to H.J. Lu from comment #5)
> Why isn't the testcase checked into gcc testsuite?

Sorry, forgot... Thanks for adding.

[Bug tree-optimization/79224] [7/8 Regression] Large C-Ray slowdown

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #16 from Yuri Gribov  ---
(In reply to Markus Trippelsdorf from comment #15)
> The patch causes bootstrap failure on x86_64:
> https://gcc.gnu.org/ml/gcc-regression/2017-05/msg0.html

Might have been fixed by r249771

[Bug bootstrap/80565] [8 Regression] ICE at -O2 and -O3 in 32-bit mode (not 64-bit) on x86_64-linux-gnu (in edge_badness, at ipa-inline.c:1028)

[tetra2005 at gmail dot com]

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

--- Comment #4 from Yuri Gribov  ---
Chengnian, is this resolved?

[Bug bootstrap/80565] [8 Regression] ICE at -O2 and -O3 in 32-bit mode (not 64-bit) on x86_64-linux-gnu (in edge_badness, at ipa-inline.c:1028)

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
Posted patch in https://gcc.gnu.org/ml/gcc-patches/2017-06/msg02228.html

[Bug tree-optimization/67886] Incomplete optimization for virtual function call into freshly constructed object

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
There is a more important optimization hiding here.

Standard suggests (in 3.8.7, in n3690.pdf) that when the same source variable
is used for the instance pointer, it's dynamic type should not change. This
allows code like
  Base *p = new Derived;
  p->foo();
  p->foo();
to be optimized to
  Derived::foo(p);
  Derived::foo(p);
(which would also allow to optimize Simon's original case).

Clang currently performs this sort of optimization (see old discussion in
https://groups.google.com/forum/#!topic/llvm-dev/XPxvsEauirM and recent blog
post in http://blog.llvm.org/2017/03/devirtualization-in-llvm-and-clang.html).

This sort of optimization requires frontend knowledge so probly can't be done
solely in GIMPLE? Summon Honza to comment.

[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values

[tetra2005 at gmail dot com]

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

--- Comment #8 from Yuri Gribov  ---
Alan,(In reply to Alan Modra from comment #0)
> It looks like gcc incorrectly prefers a range test.

Alan, can we close this?

[Bug sanitizer/59454] blacklisting sanitized functions

[tetra2005 at gmail dot com]

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

--- Comment #5 from Yuri Gribov  ---
(In reply to Martin Liška from comment #4)
> I'm pasting here Jakub's opinion which I agree with:
> 
> ```
> I'm strongly against the blacklist, that is not the way things are done in
> GCC, you have corresponding attribute to mark functions you don't want to
> instrument, people can macroize that with
> __typeof (symbol) symbol __attribute__((__no_sanitize_address__));
> But in any case, you mark it in the code rather than adding externally
> some symbol list.

Well, blacklists simplify integration of Asan to large codebases (e.g. full
Linux distro) where you often don't have the luxury of modifying the source
code. I believe was the main reason why they were added to Clang's sanitizer.

Just to double check, what are the technical arguments against using
blacklists?

[Bug tree-optimization/81089] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in register_edge_assert_for_2, at tree-vrp.c:5023

[tetra2005 at gmail dot com]

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

--- Comment #8 from Yuri Gribov  ---
(In reply to Markus Trippelsdorf from comment #7)
> You could try again:  https://cfarm.tetaneutral.net/users/new/
> From what I understand they have a new admin team in place.
> In the past the account creation latency was very high (several months).
> Not sure if it has improved yet.

Wow, I got access to machines in a few hours! Thanks for the tip. I sent
request to gccdev to update cfarm wiki
(https://gcc.gnu.org/ml/gcc/2017-06/msg00097.html).

[Bug tree-optimization/81089] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in register_edge_assert_for_2, at tree-vrp.c:5023

[tetra2005 at gmail dot com]

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

--- Comment #6 from Yuri Gribov  ---
(In reply to Markus Trippelsdorf from comment #5)
> (In reply to Yuri Gribov from comment #4)
> > Created attachment 41551 [details]
> > Draft patch
> > 
> > Here's a draft patch. It fixes the repro but bootstrapping will take some
> > time on my notebook.
> 
> There is no need to use your notebook for bootstrapping and testing.
> Why not simply use the GCC Compile Farm?
> https://cfarm.tetaneutral.net/machines/list/

That would be lovely but I tried once (by sending mail to laur...@guerby.net)
and got no reply...

In any case, the patch has been posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01092.html

[Bug tree-optimization/81089] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in register_edge_assert_for_2, at tree-vrp.c:5023

[tetra2005 at gmail dot com]

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

--- Comment #4 from Yuri Gribov  ---
Created attachment 41551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41551=edit
Draft patch

Here's a draft patch. It fixes the repro but bootstrapping will take some time
on my notebook.

[Bug tree-optimization/81089] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in register_edge_assert_for_2, at tree-vrp.c:5023

[tetra2005 at gmail dot com]

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

--- Comment #3 from Yuri Gribov  ---
Mine.

[Bug tree-optimization/67731] Combine of OR'ed bitfields should use bit-test

[tetra2005 at gmail dot com]

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

--- Comment #6 from Yuri Gribov  ---
(In reply to rguent...@suse.de from comment #5)
> On Fri, 9 Jun 2017, tetra2005 at gmail dot com wrote:
> 
> > This should probly go to reassoc? Or better keep it in folder?
> 
> As loads are involved it doesn't really fit reassoc.  Likewise it doesn't
> really fit the folder.

The || case is optimized by the folder.

[Bug tree-optimization/67731] Combine of OR'ed bitfields should use bit-test

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
(In reply to rguent...@suse.de from comment #3)
> The various patches to
> lower bitfield accesses made this work automagically.  Thus this
> PR is probably a dup of some other(s).

Interestingly, a slightly different code works fine:
  return s->b || s->c;  // || instead of |
This happens because it compiles to
  (s->b != 0) || (s->c != 0)
Each component is converted to BIT_FIELD_REF by optimize_bit_field_compare and
results are folded to a single BIT_AND.

With original use-case this does not work because we don't know that result
will be NE-ed when trying to fold IOR in fold_binary_loc.

Ideally we want to detect generic patterns like
  (s->f1 | s->f2 | ... | s->fN | other unrelated conds) != 0  // Or &, or ==
sort fi's to groups according to their memory location and optimize from there.
This should probly go to reassoc? Or better keep it in folder?

[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[tetra2005 at gmail dot com]

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

--- Comment #11 from Yuri Gribov  ---
(In reply to Tavian Barnes from comment #10)
> > I think it is - __cancel_arg is assigned inside a while loop
> 
> Specifically a do { } while(0); loop, which obviously has only one iteration.

Actually I was talking about surrounding while
((double)future->progress/future->total < progress)...

[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[tetra2005 at gmail dot com]

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

--- Comment #9 from Yuri Gribov  ---
(In reply to Tavian Barnes from comment #7)
> But this condition is not met:
> 
>> - They are changed between the setjmp() invocation and longjmp() call.

I think it is - __cancel_arg is assigned inside a while loop and can thus be
overwritten on successive iterations (compiler doesn't know that longjmp will
only be from the same iteration).

[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[tetra2005 at gmail dot com]

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

--- Comment #8 from Yuri Gribov  ---
(In reply to Yuri Gribov from comment #6)
> the warning is issued for variables which are alive after return
> from longjmp

Meant setjmp of course.

[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #6 from Yuri Gribov  ---
Hm, isn't this a valid warning about bad code in pthread.h? As can be see in
https://github.com/gcc-mirror/gcc/blob/67b5f619e75b3085374598d6f0626ec00d4c9de6/gcc/function.c#L4389
, the warning is issued for variables which are alive after return from longjmp
but not marked as volatile. Such variables will have undefined value according
to C standard (http://pubs.opengroup.org/onlinepubs/7908799/xsh/longjmp.html).

Namely in this case, __cancel_arg and __cancel_routine are used after longjmp
(it's the case of __not_first_call != 0) and are not marked volatile so their
values are effectively undefined. I checked that adding volatile to them
supresses warnings.

[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily

[tetra2005 at gmail dot com]

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

--- Comment #12 from Yuri Gribov  ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Yuri Gribov from comment #9)
> > (In reply to Alexander Monakov from comment #8)
> > > Well, if my argument is correct, then GCC generates wrong code for the 
> > > very
> > > first example in comment #0.
> > 
> > I believe it does (see my #5, most probly author of some pass failed to
> > check for interposition).  Note that simple recursive factorial is expanded
> > to loop too which is a more impressive instance of this bug.
> > 
> > > To my knowledge, that
> > > is the sole instance where optimization doesn't fully honor ELF
> > > interposition possibility.
> > 
> > +1
> 
> Don't we also inline any beneficial inline functions at -O3 even if they
> could be interposed (definitely not suggesting we stop doing that, that
> would totally kill compiler performance)?

Inlining inline functions is fine due to ODR rule.

[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values

[tetra2005 at gmail dot com]

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

--- Comment #6 from Yuri Gribov  ---
(In reply to Oleg Endo from comment #5)
> PR 67731 maybe related or dup?

Related but not a dup. This bug is caused by frontend folding two bitfield
accesses to a single comparison which prevented generation of bit test later in
tree-opt.

[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
Proposed patch in https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01936.html

[Bug c/40528] Add a new ifunc attribute

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #17 from Yuri Gribov  ---
(In reply to Agner Fog from comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > (In reply to comment #13)
> > > > What is the status of this issue?
> > > 
> > > It is implemented on ifunc branch.
> > > 
> > > > Is option 3 implemented?
> > > 
> > > Yes, on ifunc branch.
> > > 
> > > > Which versions of Linux and binutils support IFUNC?
> > Still doesn't work. 
> > "warning: ‘ifunc’ attribute directive ignored"
> > GNU Binutils for Ubuntu 2.21.0.20110327
> 
> The ifunc attribute is described in
> http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html but it doesn't
> work (see my previous comment).

Works fine in Ubuntu 16.04 (GCC 5.4, BU 2.26, Glibc 2.23).  Could someone close
this?

[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily

[tetra2005 at gmail dot com]

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

--- Comment #9 from Yuri Gribov  ---
(In reply to Alexander Monakov from comment #8)
> Well, if my argument is correct, then GCC generates wrong code for the very
> first example in comment #0.

I believe it does (see my #5, most probly author of some pass failed to check
for interposition).  Note that simple recursive factorial is expanded to loop
too which is a more impressive instance of this bug.

> To my knowledge, that
> is the sole instance where optimization doesn't fully honor ELF
> interposition possibility.

+1

[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily

[tetra2005 at gmail dot com]

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

--- Comment #7 from Yuri Gribov  ---
(In reply to Alexander Monakov from comment #6)
> Note that even without symbol aliases, such calls are not necessarily
> self-recursive when 'f' is first called via dlsym with RTLD_NEXT or a
> specific module as the first argument.

Right.  It seems -fno-semantic-interposition is the only option to disable
strict interposition rules.

So could someon close this as wontfix?

[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov  ---
Created attachment 40562
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40562=edit
Draft patch

(In reply to Thiago Macieira from comment #0)
> What's more, since the argument wasn't used, it's also
> unnecessary to set it.

This may be due to contrivedness of example (endless loop, etc.). The argument
seems to be forwarded in normal cases.

(In reply to Jan Hubicka from comment #3)
> The canonical way to do it is to create a static alias and the redirect call
> to the alias. We do that in FE for some specific examples (like thunks) but
> not in general.  Doing so would indeed make sense.

Would something like attached draft patch be ok?

(In reply to Jakub Jelinek from comment #4)
> Note it would need to be done with lots of care, because you can e.g. have
> aliases to the function and in that case you should go through the PLT:

Note that we already violate this. E.g. in Thiago's reprocase compiler
shouldn't have figured out
that there is and endless loop. I can also see that recursive factorial
implementation is expanded to loop
even under -fPIC. Should I fix this?

[Bug middle-end/77622] __builtin_object_size incorrect for an out-of-bounds pointer prior to destination object

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||tetra2005 at gmail dot com

--- Comment #1 from Yuri Gribov  ---
Sounds like an important use-case. I did some basic debugging and it turns out
that "[3] - 10" is represented as POINTER_PLUS_EXPR with (size_t)-10 offset.
For some reason tree-object-size.c deliberately skips POINTER_PLUS_EXPRs with
offset > offset_limit where offset_limit is (size_t)-1 / 2 so negative offsets
are effectively ignored.

Added Jakub to maybe comment on this behavior as that's his code.

[Bug tree-optimization/66826] Unused result from dlsym in constructor results in a segfault

[tetra2005 at gmail dot com]

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

--- Comment #6 from Yuri Gribov  ---
(In reply to Rich Felker from comment #5)
> maybe there are workarounds glibc could do to prevent tco without needing a
> new attribute...

X-posted to Glibc BZ: https://sourceware.org/bugzilla/show_bug.cgi?id=21050

[Bug libgcc/67336] Verify pointers during stack unwind

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
Posted RFC in https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00793.html

[Bug libgcc/58120] libgcc.a and libgcc_eh.a have incorrect symbol visibility

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #1 from Yuri Gribov  ---
Does not reproduce with arm-linux-gnueabi-gcc 5.4.0, all symbols in libgcc.a
are hidden.

[Bug tree-optimization/66826] Unused result from dlsym in constructor results in a segfault

[tetra2005 at gmail dot com]

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

--- Comment #4 from Yuri Gribov  ---
As this is not a GCC bug I suggest you
* close this issue (as not-a-bug?)
* report to Glibc folks (perhaps they could do more checking of return address
or at least document their calling convention assumptions in manpages)

[Bug tree-optimization/66826] Unused result from dlsym in constructor results in a segfault

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #3 from Yuri Gribov  ---
This is a very funny bug but not related to GCC per se. Firstly, let's consider
a miminal repro:
__attribute__((constructor)) static void some_init() {
  dlsym(RTLD_DEFAULT, "anything");
}
(segfaults just as well). Under -O0 this produces a normal call:
calldlsym@PLT
...
ret
but with -O2 GCC is clever enough to tail-call-optimize it to a plain jump:
jmp dlsym@PLT

Now dlsym (and other dl-functions) secretly take shadow parameter - return
address on stack:
void *
__dlsym (void *handle, const char *name DL_CALLER_DECL)
{
...
  struct dlsym_args args;
  args.who = DL_CALLER;
  args.handle = handle;
  args.name = name;
(from dlsym.c). As in our case return address is missing, args.who argument is
missing which causes segfault during symbol resolution (dynamic linker is lame
on checks).

[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
It would be nice if there was a standard API for expressing the pattern. This
could be both tuned for particular target in std. library and
recognized/optimized by compiler. FreeBSD seems to have memcchr
(https://www.freebsd.org/cgi/man.cgi?query=memcchr) so I've risked filing
request at Glibc folks (https://sourceware.org/bugzilla/show_bug.cgi?id=21018).

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #7 from Yuri Gribov  ---
Same issue: https://github.com/google/sanitizers/issues/654

[Bug other/69050] libbacktrace: bsearch over unsorted array in unit_addrs_search

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

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

--- Comment #2 from Yuri Gribov  ---
> This will return a consistent answer if low/high ranges are always
> subsets or supersets

You are right, that's the case which I'm seeing.

> If you are encountering a problem, please describe it in more detail.

This was detected with a custom debugging tool so not a real bug. I'm closing
the issue then.

[Bug other/69050] New: bsearch over unsorted array in unit_addrs_search

[tetra2005 at gmail dot com]

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

Bug ID: 69050
   Summary: bsearch over unsorted array in unit_addrs_search
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tetra2005 at gmail dot com
  Target Milestone: ---

Libbacktrace performs a bsearch with unit_addrs_search over address range
array. Prior to this list is qsorted with unit_addrs_compare. The algorithms in
these two functions are absolutely unrelated which in practice means that
address ranges are not sorted w.r.t. unit_addrs_search. In practice this may
cause latent bugs like inability to find an address range.

Note that this may be applicable to other bsearch calls although to now I've
only experienced errors for unit_addrs_search at runtime.

[Bug testsuite/66046] UBSan output pattern tests fail on target ARM board.

[tetra2005 at gmail dot com]

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

--- Comment #2 from Yuri Gribov tetra2005 at gmail dot com ---
The question is what's more appropriate.  Doing this repetative work like this
demotivates folks.  But if Marek promises to never add newlines to his regexps
again we can submit another cleanup patch :)

[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[tetra2005 at gmail dot com]

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

Yuri Gribov tetra2005 at gmail dot com changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #8 from Yuri Gribov tetra2005 at gmail dot com ---
 So, I wonder, if it's a testcase problem and
 it should be disabled for CA8?

Perhaps add CA8 check in check_effective_target_arm_vect_no_misalign in
gcc/testsuite/lib/target-supports.exp?

[Bug c/62141] [GCC-4.10.0][ASAN] ICE: Segmentation fault: 11

[tetra2005 at gmail dot com]

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

Yuri Gribov tetra2005 at gmail dot com changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov tetra2005 at gmail dot com ---
I couldn't repro with fresh trunk on x86_64-apple-darwin12.5.0 and
x86_64-unknown-linux-gnu.

[Bug sanitizer/61875] ATRIBUTE_NONNULL macro error

[tetra2005 at gmail dot com]

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

Yuri Gribov tetra2005 at gmail dot com changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov tetra2005 at gmail dot com ---
Libsanitizer does not support building with -fexceptions. Patch was proposed in
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01764.html

[Bug middle-end/62140] [GCC-4.10.0][ASAN] ICE: : in build2_stat, at tree.c:4265

[tetra2005 at gmail dot com]

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

Yuri Gribov tetra2005 at gmail dot com changed:

   What|Removed |Added

 CC||jakub at redhat dot com,
   ||tetra2005 at gmail dot com

--- Comment #3 from Yuri Gribov tetra2005 at gmail dot com ---
This is probably duplicate of #61897 .

[Bug testsuite/62060] g++.dg/tsan/cond_race.C triggers heap-use-after-free

[tetra2005 at gmail dot com]

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

Yuri Gribov tetra2005 at gmail dot com changed:

   What|Removed |Added

 CC||kcc at gcc dot gnu.org

--- Comment #4 from Yuri Gribov tetra2005 at gmail dot com ---
Adding kcc. It may make sense to detect testsuite changes during libsanitizer
merges.

[Bug testsuite/62060] g++.dg/tsan/cond_race.C triggers heap-use-after-free

[tetra2005 at gmail dot com]

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

Yuri Gribov tetra2005 at gmail dot com changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Yuri Gribov tetra2005 at gmail dot com ---
Also added Jakub. Looks like LLVM and GCC use orthogonal approaches to deflake
TSan tests: GCC does this in source code
(https://groups.google.com/forum/#!topic/thread-sanitizer/KIok3F_b1oI) whereas
LLVM chose to go with retrying testrunner
(http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/218813.html).

[Bug sanitizer/61547] Invalid sanitization of trailing byte in __builtin_strlen

[tetra2005 at gmail dot com]

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

Yuri Gribov tetra2005 at gmail dot com changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov tetra2005 at gmail dot com ---
Yeah, GCC is different in this regard.

[Bug sanitizer/61530] [4.10 Regression] segfault with asan

[tetra2005 at gmail dot com]

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

Yuri Gribov tetra2005 at gmail dot com changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov tetra2005 at gmail dot com ---
Actually the fix may not handle unaligned addresses properly. I think we should
rather stick with start and end bytes for memory regions in builtins. What's
your opinion?

[Bug other/60681] Libbacktrace library doesn't work with QEMU in application mode

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681

Yuri Gribov tetra2005 at gmail dot com changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov tetra2005 at gmail dot com ---
(In reply to Maxim Ostapenko from comment #0)
 After investigation I discovered that libbacktrace scans /proc/self/exe to
 init symbolizer and in QEMU case it finds information about qemu-arm binary
 itself, not a.out.

I think this needs to be fixed (or rather implemented) in QEMU. They already
intercept accesses to /proc/self/{maps,stat,auxv}.

See https://github.com/qemu/qemu/blob/master/linux-user/syscall.c

[Bug other/60681] Libbacktrace library doesn't work with QEMU in application mode

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681

--- Comment #3 from Yuri Gribov tetra2005 at gmail dot com ---
(In reply to Yuri Gribov from comment #2)
 I think this needs to be fixed (or rather implemented) in QEMU.

QEMU bug: https://bugs.launchpad.net/qemu/+bug/1299190

[Bug sanitizer/59585] Tests failing due to trailing newline

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59585

--- Comment #4 from Yuri Gribov tetra2005 at gmail dot com ---
Yup, thanks.

[Bug sanitizer/59454] blacklisting sanitized functions

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454

--- Comment #2 from Yuri Gribov tetra2005 at gmail dot com ---
Proper link to Fortran attr bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209

[Bug sanitizer/59454] blacklisting sanitized functions

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454

Yuri Gribov tetra2005 at gmail dot com changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #1 from Yuri Gribov tetra2005 at gmail dot com ---
I guess what you really need is equivalent of 
__attribute__((no_address_safety_analysis)) in Fortran land. People have been
talking about supporting attributes in GNU Fortran for ages (see #41209) but it
never got anywhere.

[Bug sanitizer/58718] Invalid check in libsanitizer

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718

--- Comment #7 from Yuri Gribov tetra2005 at gmail dot com ---
(In reply to Kostya Serebryany from comment #6)
 Can we keep this bug in one place, please? 
 Let https://code.google.com/p/address-sanitizer/issues/detail?id=239 be the
 primary one

Ok, will do. I'm a little gcc-biased as you know.

[Bug sanitizer/58680] Spurious warnings from libasan

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58680

--- Comment #2 from Yuri Gribov tetra2005 at gmail dot com ---
/* Answering from my personal account */

According to http://marc.info/?t=13645834152 this may not be a problem for
Android. It seems that NDK links shared libs with -Bsymbolic which should
prevent interpositions like this. Haven't verified this though, no Android
device at hand...

-Y

[Bug c/41809] escaping address of packed field should trigger warning

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41809



--- Comment #3 from Yuri Gribov tetra2005 at gmail dot com 2012-10-18 
11:38:45 UTC ---

Created attachment 28481

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28481

Another testcase



Testcase which demonstrates more issues.

[Bug c/41809] escaping address of packed field should trigger warning

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41809



Yuri Gribov tetra2005 at gmail dot com changed:



   What|Removed |Added



 CC||tetra2005 at gmail dot com



--- Comment #4 from Yuri Gribov tetra2005 at gmail dot com 2012-10-18 
11:41:10 UTC ---

Gcc does warn (actually it even errs) if you try to pass unaligned variable by

reference but does not do this when you use pointers:

  $ g++ -Wall -c pack_warns.cpp

  pack_warns.cpp:22:9: error: cannot bind packed field 't-Test::x' to 'float'



Also it'll fail to warn if you use #pragma pack instead of

__attribute__((packed)):

  $ g++ -Wall -c -DUSE_PRAGMA pack_warns.cpp   # Compiles wo warnings



Just wanted to mention that users frequently run into errors with unaligned

data (especially on targets where it really matters e.g. on ARM) so this might

be important issue.

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831

--- Comment #23 from Yuri Gribov tetra2005 at gmail dot com 2012-07-10 
15:34:02 UTC ---
The C++ Standard says that an inline function shall be defined in every
translation unit in which it is used (n1905, 7.1.2). The test in question
violates this rule: definition for C::f() is present only in impl.cpp.

Should we consider the test invalid?

[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831

--- Comment #22 from Yuri Gribov tetra2005 at gmail dot com 2012-07-04 
12:32:08 UTC ---
 For non fat (slim) LTO builds you need to use these tools yes

So it seems that original testcase with fat files which used plain ar is indeed
correct and we have a real bug.

[Bug lto/53831] Inline virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831

--- Comment #3 from Yuri Gribov tetra2005 at gmail dot com 2012-07-03 
10:45:09 UTC ---
I don't think linker can do much after gcc removes the symbol from symtab.

BTW it would help a lot if linker verified that LTO and ELF symtabs actually
match. Currently mismatches causes all sorts or weird errors which are somewhat
hard to understand without getting your hands dirty.

[Bug lto/53831] Inline virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831

--- Comment #6 from Yuri Gribov tetra2005 at gmail dot com 2012-07-03 
12:16:21 UTC ---
First of all note that we are talking about _ZN1C1fEv (not _ZN1C1gEv!) here.

I agree that linker doesn't mention it in the resolution file but I think this
happens because it's missing in impl.o's lto_.symtab section:
  $ cat impl.s | grep -C 5 lto_.symtab
  ...
  .section.gnu.lto_.symtab.919ce2eae4796a64,,%progbits
  .ascii  _ZN1C1gEv\000\000\000\000\000\000\000\000\000\000\000
  .ascii  \000\241\000\000\000_ZTV1C\000\000\000\000\000\000\000
  .ascii  \000\000\000\000\000\265\000\000\000
  .text
  .section.gnu.lto_.opts,,%progbits
Thus it isn't reported to linker by lto-plugin via add_symbols() (see
ld/plugin.c). So linker doesn't have a chance to know that _ZN1C1fEv is
actually defined in impl.o and generates invalid resolution. I still think that
ld is innocent here.

Did I get it all wrong?

[Bug lto/53831] Inline virtuals missing in LTO symtab

[tetra2005 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831

--- Comment #10 from Yuri Gribov tetra2005 at gmail dot com 2012-07-03 
12:59:01 UTC ---
 if I use -fno-fat-lto-objects I get a maybe more easily to debug linker 
 failure

I guess that's because in this case archive symtab doesn't reference any
symbols at all (which is another bug):
  $ nm libdummy.a 
  impl.o:
  0001 C __gnu_lto_slim
  0001 C __gnu_lto_v1
so linker doesn't get any symbols from impl.o (not even _ZTV1C).

 Or your program is invalid because you have no inline definition where you
have a use.

I'm not sure whether inline virtual without definition is valid in C++. But I
googled a bit before submitting the bug and found no evidence that it's a
non-standard (and more importantly - non-lto g++ accepts this code
just fine).