https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95693
Bug ID: 95693
Summary: Incorrect error from undefined behavior sanitizer
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #38 from Andrew Downing ---
> int *p;
> int x;
> if ()
>p =
> else
>p = malloc (4);
> memcpy (p, q, 4);
>
> there is a single memcpy call and the standard says that both the dynamic
> type transfers (from q) and that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95683
--- Comment #1 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:beaf12b49ae030505194cdcac18b5c8533a43921
commit r11-1346-gbeaf12b49ae030505194cdcac18b5c8533a43921
Author: Kito Cheng
Date: Tue Jun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95676
--- Comment #2 from James McCoy ---
Apologies for leaving off the build/configure information. I shouldn't have
assumed one would have access to Debian's compiler.
--8<--
abel% g++ -v
Using built-in specs.
COLLECT_GCC=g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95685
--- Comment #1 from Jim Wilson ---
The problem with the constant isn't apparent until we reach RTL generation and
see that it requires two instructions to load. Then once in RTL optimization
passes we have mostly block local optimizations that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95632
--- Comment #4 from Jim Wilson ---
Created attachment 48737
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48737=edit
proof of concept patch for changing xor with a large constant
needs cleanup and testing to be useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95632
--- Comment #3 from Jim Wilson ---
It isn't possible to have patterns that match only in combine. If we add a
pattern to accept (xor (reg) (large constant)) then it could match in any
optimization pass, and could prevent us from optimizing away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637
--- Comment #3 from Jim Wilson ---
People have asked about constant pools before, but as far as I know no one has
tried to implement support for them yet.
We don't have a pc-relative load, so it would be a two instruction sequence
with auipc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95672
Nicholas Krause changed:
What|Removed |Added
CC||xerofoify at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95692
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2020-06-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95692
Bug ID: 95692
Summary: PPC64, suspicious store in front of inline assembly
section
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #37 from Richard Smith
---
(In reply to Richard Biener from comment #36)
> The main issue I see is that this differing expectations of C and C++ are
> impossible to get correct at the same time.
That is a rather bold claim. I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95687
--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch posted for review:
https://gcc.gnu.org/pipermail/fortran/2020-June/054527.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95691
Bug ID: 95691
Summary: Functions for case insensitive comparison of wide
strings are not implemented
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95687
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95689
--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch submitted for review:
https://gcc.gnu.org/pipermail/fortran/2020-June/054525.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95689
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #37 from qinzhao at gcc dot gnu.org ---
So, the previous prof data size for the real application might not be correct.
After this bug is fixed, we might need to collect the new real code size
reduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #36 from qinzhao at gcc dot gnu.org ---
I found a bug with this proposed patch:
when doing automatic merging, the following error message is emitted:
Merge mismatch for function 1.
the bug can be repeated with the small testing case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95687
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-06-15
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95690
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95688
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-06-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95689
Martin Liška changed:
What|Removed |Added
CC||aldot at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95690
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95662
--- Comment #2 from Bill Seurer ---
OK. If you fix the other one I will try it and see if it fixes this, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #22 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #21)
> As for a workaround for memory leaks, you can always add
>
> if (.not. allocated(a)) deallocate (a)
Of course, that should be
if (allocated(a))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95690
Bug ID: 95690
Summary: [11 Regression] ICE in
set_mem_attributes_minus_bitpos, at emit-rtl.c:2092
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95689
Bug ID: 95689
Summary: ICE in check_sym_interfaces, at
fortran/interface.c:2015
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95688
Bug ID: 95688
Summary: ICE in gfc_get_string, at fortran/iresolve.c:70
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95687
Bug ID: 95687
Summary: ICE in get_unique_hashed_string, at
fortran/class.c:508
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95672
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95662
--- Comment #1 from Aldy Hernandez ---
This is likely a duplicate of pr95649 (see my note there), but I cannot verify
as I don't have access to the spec2006 sources.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95678
--- Comment #2 from Matthias Klose ---
the gcc-9 branch from 20200408 works for me. 20200615 also fails.
: In instantiation of ‘decltype (c::d{l}) c::operator()(bb, e) [with bb =
int*; e = unsigned int; b = int*]’:
:9:37: internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95686
Bug ID: 95686
Summary: undefined reference to static local variable within
inline function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95653
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649
Aldy Hernandez changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Aldy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95625
Martin Sebor changed:
What|Removed |Added
Component|c++ |c
--- Comment #1 from Martin Sebor ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95680
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95684
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95680
--- Comment #1 from Iain Buclaw ---
(In reply to H.J. Lu from comment #0)
> libdruntime manipulates user stack. It doesn't support shadow stack from
> Intel CET:
>
> https://software.intel.com/content/www/us/en/develop/articles/intel-sdm.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95684
Marek Polacek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95562
Marek Polacek changed:
What|Removed |Added
CC||janezz55 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95684
--- Comment #3 from Janez Zemva ---
Isn't a link to the source code sufficient? You can generate your own, if you
want.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95685
Bug ID: 95685
Summary: Loop invariants can't be moved out of the loop
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95684
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95684
--- Comment #1 from Janez Zemva ---
Everything works with clang version 10.0.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95684
Bug ID: 95684
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
--- Comment #13 from Maxim Britov ---
New report https://bugzilla.kernel.org/show_bug.cgi?id=208187
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95683
Kito Cheng changed:
What|Removed |Added
Last reconfirmed||2020-06-15
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95683
Bug ID: 95683
Summary: internal compiler error: in
riscv_gpr_save_operation_p, at
config/riscv/riscv.c:5219
Product: gcc
Version: unknown
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95682
Bug ID: 95682
Summary: Default assignment fails with allocatable array of
deferred-length strings
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95681
Bug ID: 95681
Summary: False positive uninitialized variable usage in
decNumberCompareTotalMag
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: build,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95674
--- Comment #2 from H.J. Lu ---
PR 95442 is also REG_DEAD related.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95680
Bug ID: 95680
Summary: libdruntime doesn't support shadow stack
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
--- Comment #12 from Jakub Jelinek ---
Please report it to kernel bugzilla or whatever objtool has bugtracker.
https://bugs.gentoo.org/642924
is very likely exactly the same thing, but not sure if they have reported it
upstream.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95524
--- Comment #3 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #0)
> icc has
> ---
> ashift(char __vector(16)):
> vpsllwxmm1, xmm0, 5 #9.16
> vpand xmm0, xmm1, XMMWORD PTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #23 from H.J. Lu ---
Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95524
--- Comment #2 from Hongtao.liu ---
Microbenchmark show on Skylake client
---
benchmark Skylake client
ashift improvement
v16qi 13%
v32qi 5%
v64qi 7%
ashiftrt
v16qi 5%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #8 from rguenther at suse dot de ---
On Mon, 15 Jun 2020, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
>
> --- Comment #7 from Jonathan Wakely ---
> So yes, the static_cast should evaluate to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95676
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95646
avieira at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-06-15
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #7 from Jonathan Wakely ---
So yes, the static_cast should evaluate to zero, but if it's followed by a
dereference then it seems reasonable to expect -fdelete-null-pointer-checks to
optimize away the handling for zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #6 from Jonathan Wakely ---
Dereferencing in the null case is undefined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #5 from rguenther at suse dot de ---
On Mon, 15 Jun 2020, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
>
> --- Comment #3 from Jonathan Wakely ---
> Or to be more clear:
>
> struct Large {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677
Nathan Sidwell changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
--- Comment #10 from Martin Liška ---
Yep, I've already created a reduced-testcase myself:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671#c6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95678
Richard Biener changed:
What|Removed |Added
Known to work||9.3.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
--- Comment #9 from Maxim Britov ---
Created attachment 48733
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48733=edit
gcc -E ...
I believe attachment is what you aksed. I did
gcc -E -Wp,-MD,arch/x86/entry/vsyscall/.vsyscall_64.o.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
Martin Liška changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677
--- Comment #4 from Richard Biener ---
(In reply to liusujian from comment #2)
> (In reply to Richard Biener from comment #1)
> > It's more likely the GENERIC / cgraph output by the C++ frontend is not
> > correct
> > and works by accident
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #8 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677
--- Comment #3 from Nathan Sidwell ---
I think the testcase is should be formed. it was ok in C++98, but that changed
when anonymous namespaces gave their contents internal linkage (rather than
external but with unpronounceable symbols).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
--- Comment #7 from Andreas Schwab ---
make arch/x86/entry/vsyscall/vsyscall_64.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #4 from John Zwinck ---
Richard Biener said:
> Note it will make a difference for very large objects (and thus very large
> offsets added) which may end up accessing actually mapped memory so IMHO what
> clang does by default is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
--- Comment #6 from Martin Liška ---
(In reply to Maxim Britov from comment #4)
> (In reply to Martin Liška from comment #1)
> > Can you please attach a pre-processed file for an object that fails with
> > objtool?
>
> Heh... I'm afraid I need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
--- Comment #5 from Maxim Britov ---
Created attachment 48732
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48732=edit
some minimal config for kerknel 5.7 for reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
--- Comment #4 from Maxim Britov ---
(In reply to Martin Liška from comment #1)
> Can you please attach a pre-processed file for an object that fails with
> objtool?
Heh... I'm afraid I need some howto for this... :(
But I made some minimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95672
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95671
--- Comment #3 from Maxim Britov ---
(In reply to Richard Biener from comment #2)
> Assuming GCC 10.1 - you didn't specify.
In my env I can reproduce it on 8.3.0 / 9.2.0 / 9.3.0/ 10.1.0
Using built-in specs.
COLLECT_GCC=gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95679
Bug ID: 95679
Summary: [11 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
type_has_mode_precision_p, at tree.h:6231
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87515
--- Comment #6 from Jonathan Wakely ---
(In reply to ipelupes from comment #4)
> also: adding __builtin_unreachable(); hides the warning making it even
> harder to find
Don't do that then :)
Adding that promises the compiler your program will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #3 from Jonathan Wakely ---
Or to be more clear:
struct Large {
char pad[1024*1024];
int x;
};
Large* p = 0;
int i = p->x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #2 from Jonathan Wakely ---
(In reply to Richard Biener from comment #1)
> I suppose the C++ standard says static_cast(nullptr) == nullptr
> and
> we literally follow that. Note it will make a difference for very large
> objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95657
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95632
--- Comment #2 from Mel Chen ---
(In reply to Jim Wilson from comment #1)
> We sign extend HImode constants as that is the natural thing to do to make
> arithmetic work. This does mean that unsigned short logical operations need
> a zero extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #36 from Richard Biener ---
(In reply to Andrew Downing from comment #35)
> I agree that the new implicit object creation rules sound very difficult to
> implement correctly especially because the behavior in C is different. I'm
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95678
Bug ID: 95678
Summary: [9 Regression] ICE in dependent_type_p, at
cp/pt.c:25610
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551
Bug 95551 depends on bug 94848, which changed state.
Bug 94848 Summary: [Offloading][LTO] error due to only partially eliminated var
/ -ftree-pre causes link errors |
libgomp.fortran/use_device_ptr-optional-3.f90 failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95583
Bug 95583 depends on bug 95551, which changed state.
Bug 95551 Summary: [OpenMP, OpenACC] -fopenmp/-fopenacc also with
-foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to
`A.10.2'
1 - 100 of 117 matches
Mail list logo
