https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #14 from James Hilliard ---
(In reply to David Faust from comment #13)
> Created attachment 54017 [details]
> DATASEC entries for extern funcs
>
> Applies on top of 54002: updated patch
> Adds emission of DATASEC entries for extern
ra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221205 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107978
Bug ID: 107978
Summary: ICE: tree check: expected class 'type', have
'exceptional' (error_mark) in dump_ada_declaration, at
c-family/c-ada-spec.cc:2802 with -fdump-ada-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107976
--- Comment #1 from Andrew Pinski ---
ncases = tree_to_shwi (range) + 1;
labelvec = XALLOCAVEC (rtx, ncases);
memset (labelvec, 0, ncases * sizeof (rtx));
I think this is a won't fix.
Doctor, it hurts when I bend my arm this way.
Don't b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107968
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-12-05
Ever confirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107978
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
Bug ID: 107979
Summary: [13 regression] r13-4391-g0ded30b361d2b1 causes excess
errors in 17_intro/names.cc on big endian
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
--- Comment #1 from seurer at gcc dot gnu.org ---
Oh, also these:
FAIL: experimental/names.cc (test for excess errors)
FAIL: experimental/names.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107922
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106757
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
--- Comment #3 from Andrew Pinski ---
https://sourceware.org/git/?p=glibc.git;a=commit;h=d1d9eaf478b7d3a11a599c120498b79fe5629a61
was the change in glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
Bug ID: 107980
Summary: va_start incorrectly accepts an arbitrary number of
arguments in C2x
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #12 from Jason Merrill ---
Another significant part of the problem is that vector doesn't have a
generic initializer_list constructor. Adding
template
_GLIBCXX20_CONSTEXPR
vector(initializer_list<__elt> __l,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107981
Bug ID: 107981
Summary: 'operator auto' has not been declared in base
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #1 from Andrew Pinski ---
Hmm from https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf :
```
7.16.1.4 The va_start macro
void va_start(va_list ap, ...);
Any additional arguments are not used by
the macro and will not be expa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #13 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #11)
> Even if we don't emit a loop (which I still think is the way to go for
> larger initializers because anything else means just too large code), can't
> there fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107981
--- Comment #1 from Egor Pugin ---
Also see following test cases.
===
ok for gcc
struct a {
operator auto();
};
struct b : a {
using a::operator auto;
};
===
not ok for gcc&clang, ok for msvc
struct a {
operator auto();
};
stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107981
--- Comment #2 from Egor Pugin ---
Ignore previous comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #2 from Aaron Ballman ---
(In reply to Andrew Pinski from comment #1)
> Hmm from https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf :
> ```
> 7.16.1.4 The va_start macro
> void va_start(va_list ap, ...);
>
>
> Any additiona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
David Faust changed:
What|Removed |Added
Attachment #54017|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Summary|va_start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> I think we should warn but how to warn is going to have to special case the
> macro I think.
But saying that I do think it is valid C2X code if you take the C2X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
--- Comment #4 from seurer at gcc dot gnu.org ---
These systems are pretty old. So, just ignore it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107968
--- Comment #2 from anlauf at gcc dot gnu.org ---
The following attempt fixes the erroneous output:
diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
index 9f86815388c..c4525f67ef3 100644
--- a/gcc/fortran/trans-io.cc
+++ b/gcc/fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #16 from James Hilliard ---
(In reply to David Faust from comment #15)
> Created attachment 54021 [details]
> [v2] DATASEC entries for extern funcs
>
> v2 fixes an off-by-one bug introduced in the patch which was causing
> libbpf: I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #14 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #12)
> Another significant part of the problem is that vector doesn't have
> a generic initializer_list constructor. Adding
>
> template
> _GLIBCXX20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107982
Bug ID: 107982
Summary: ICE in in lower_bound, at value-range.h:350
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: midd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #15 from Jakub Jelinek ---
So, do we want a new attribute on allocator to tell the compiler that it is a
class whose methods don't care about the address of the object and it has
trivial ctor and dtor and it is enough to construct it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107982
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
Target Milestone|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107975
Jakub Jelinek changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107982
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106325
--- Comment #4 from David Malcolm ---
Created attachment 54023
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54023&action=edit
Reduced reproducer
Attached is a reduced version of the reproducer, which demonstrates the false
+ve on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106325
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106325
--- Comment #6 from David Malcolm ---
Fix for the overzealous reducing is to simply add "__attribute__((nonnull(1,
2)))" to the reproducer here:
__attribute__((nonnull(1, 2)))
void
arranger_object_unsplit (ArrangerObject *r1, ArrangerObject *r2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #16 from Jason Merrill ---
(In reply to Jonathan Wakely from comment #14)
> > Jonathan, has anyone suggested adding generic init_list constructors to the
> > container classes?
>
> Not that I'm aware of. There might be concerns abou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107983
Bug ID: 107983
Summary: btf: bad call relo against
'test_task_acquire_release_current' in section
'tp_btf/task_newtask'
Product: gcc
Version: 13.0
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107983
--- Comment #1 from James Hilliard ---
Working LLVM btf dump:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug btf dump file
/home/buildroot/bpf-next/tools/testing/selftests/bpf/task_kfunc_success.bpf.linked3.o
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
--- Comment #6 from caiyinyu ---
Created attachment 54024
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54024&action=edit
glibc tests build log and fails test result
build log: tmp-tst-math-2022-12-05.log
test results: test-xxx.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107970
--- Comment #1 from Hongtao.liu ---
Mine, let me fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576
--- Comment #7 from Paul Thomas ---
(In reply to Thomas Koenig from comment #6)
>
> > I hope that you are well and that the lack of time is for a good cause?
>
> Hi Paul,
>
> yes, I'm well, and the lack of time is indeed for a good cause :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107984
Bug ID: 107984
Summary: ICE: in verify_target_availability, at
sel-sched.cc:1553 with -O2 -fselective-scheduling2
-mabi=ms -mavx512vl
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107985
Bug ID: 107985
Summary: [13 Regression] ICE in as_a, at value-range.h:393
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165
--- Comment #7 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:790ff87f675f28bce5e7e35918ae09c3ece4ec4d
commit r13-4499-g790ff87f675f28bce5e7e35918ae09c3ece4ec4d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107985
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
Bug ID: 107986
Summary: [12/13 Regression] Bogus -Warray-bounds diagnostic
with std::sort
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-12-06
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165
--- Comment #8 from Richard Biener ---
I have opened PR107986 for the testcase in comment#2 which isn't yet fixed on
trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
Richard Biener changed:
What|Removed |Added
Blocks||85316
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
--- Comment #2 from Andrew Pinski ---
(In reply to Richard Biener from comment #1)
>
> void bar ();
> void foo (int *a)
> {
> int qa = 0;
> for (int i = 0; i < 3; i++)
> if (a[i])
> a[qa++] = 0;
> if (qa > 3)
> bar ();
> }
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
--- Comment #4 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Richard Biener from comment #1)
> >
> > void bar ();
> > void foo (int *a)
> > {
> > int qa = 0;
> > for (int i = 0; i < 3; i++)
> > if (a
101 - 155 of 155 matches
Mail list logo
