https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110429
--- Comment #1 from CVS Commits ---
The master branch has been updated by HaoChen Gui :
https://gcc.gnu.org/g:d471bdb0453de7b738f49148b66d57cb5871937d
commit r14-3237-gd471bdb0453de7b738f49148b66d57cb5871937d
Author: Haochen Gui
Date: Wed A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769
--- Comment #4 from CVS Commits ---
The master branch has been updated by HaoChen Gui :
https://gcc.gnu.org/g:a79cf858b39e01c80537bc5d47a5e9004418c267
commit r14-3236-ga79cf858b39e01c80537bc5d47a5e9004418c267
Author: Haochen Gui
Date: Wed A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110983
--- Comment #2 from Mao ---
I think the issue is in /gcc/doc/invoke.texi
This flag is missing under "@item Program Instrumentation Options", around line
650.
I can prepare a patch later this week or next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111028
--- Comment #5 from zhaiqiming at baidu dot com ---
(In reply to Patrick Palka from comment #4)
thanks for your plan. Because my project need -o2 optimization, i use "#pragma
GCC optimize("-O0")" to temporarily solve the problem with this functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #4 from Jerry DeLisle ---
The relative text in the standard is:
13.7.2.1 General rules
--- snip ---
(6) On output, with I, B, O, Z, D, E, EN, ES, EX, F, and G editing, the
specified value of the field width w may be zero. In such ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111034
Bug ID: 111034
Summary: Precompiled headers still non-deterministic
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109021
--- Comment #5 from Andrew Pinski ---
(In reply to Martin Uecker from comment #4)
> Sorry, how can an enhancement request that addresses a real C/C++
> compatibility problem be marked "resolved invalid" ?
Because GCC does like these days to add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #2 from john.harper at vuw dot ac.nz ---
Further information on this bug: it affects all four real kinds with all
three of E0.0E0, ES0.0E0 and EN0.0E0 formats. My 15-line test program for
that is attached. I hope it helps.
On Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111032
--- Comment #1 from Andrew Pinski ---
One way of fixing this is to optimize the following for the scalar side:
```
_15 = _4 != 0;
_16 = (short unsigned int) _15;
_17 = _16 << 3;
_6 = (int) _17;
```
into:
```
_t = (int) _15;
_6 = _t <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111033
Bug ID: 111033
Summary: libcody build does not use AR_FLAGS
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111032
Bug ID: 111032
Summary: using small types inside loops sometimes confuses the
vectorizer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111015
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
--- Comment #10 from Romain Geissler ---
Hi,
It seems the reproducers from comment #1 and #5 don't happen anymore with gcc
13 or trunk. So it seems fixed.
Cheers,
Romain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111006
--- Comment #3 from Andrew Pinski ---
Created attachment 55740
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55740&action=edit
The patch which fixes the SVE part
It took me longer to come up with this due to failures which I didn't know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87326
--- Comment #9 from Nathan Weeks ---
(In reply to anlauf from comment #8)
> (In reply to Nathan Weeks from comment #7)
> > (In reply to anlauf from comment #6)
> > > (In reply to Nathan Weeks from comment #5)
> > > > (In reply to Brad Richardson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110801
--- Comment #1 from Jonathan Wakely ---
Created attachment 55739
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55739&action=edit
Add special case for format("{}", integer)
With this patch std::format is much closer to fmt::format:
Bench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109815
--- Comment #4 from John Parke ---
Thanks for taking a look at this.
My AIX system is 7.1 TL 04 SP 05 (2017/20).
We just dropped support for 6, but still have customers on 7.1.
I'll have to see about updating this system to see if that works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
Gleb Fotengauer-Malinovskiy changed:
What|Removed |Added
CC||glebfm at altlinux dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78054
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #41 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #40)
> Harald, I have just closed the followup PR110419.
> I think this PR can be closed as well, or is there something left to be done?
It is pretty much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #13 from Mark Brown ---
The kernel hasn't got any problem with BTI as far as I am aware - when built
with clang we run the kernel with BTI enabled since clang does just insert a
BTI C at the start of every function, and GCC works fin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111029
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Faust :
https://gcc.gnu.org/g:489e1adf7792985b21195c740da7370f96b19640
commit r14-3227-g489e1adf7792985b21195c740da7370f96b19640
Author: David Faust
Date: Tue A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99232
Gregory Dushkin changed:
What|Removed |Added
CC||yagreg7 at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110860
--- Comment #19 from Paul Dreik ---
Thanks Jonathan!
I am happy to count myself as a gcc contributor now :-D
Never mind the tiny git mistake, that will be forgotten once gcc 14 is out!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #4 from Andrew Macleod ---
(In reply to Richard Biener from comment #3)
> bool
> operator_addr_expr::fold_range (irange &r, tree type,
> const irange &lh,
> const irange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105644
Patrick Palka changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #3 from Patrick Palka ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111031
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2023-08-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #17 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #16)
> > Which is what this produces:
> > ```
> > long long f(void)
> > {
> > unsigned t = 16843009;
> > long long t1 = t;
> > long long t2 = ((unsigned long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #16 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #15)
> On the branch devel/vineetg/optim-double-const-m0 I have double -0.0 working.
>
> znd:
> li a5,-1
> sllia5,a5,63
> sd a5,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019
--- Comment #4 from Sławomir Fraś ---
Not sure if that hints at the possible cause, when i extracted `this` variable
out of the loop to something like this (https://godbolt.org/z/8ebb5E1qG):
Target* first = this;
while (first->next)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111031
Bug ID: 111031
Summary: ICE: internal compiler error: in
iterative_hash_template_arg, at cp/pt.cc:1747
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111025
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
Bug 103227 depends on bug 92497, which changed state.
Bug 92497 Summary: Aggregate IPA-CP and inlining do not play well together,
transformation is lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92497
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92497
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68930
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92497
--- Comment #4 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:d073e2d75d9ed492de9a8dc6970e5b69fae20e5a
commit r14-3226-gd073e2d75d9ed492de9a8dc6970e5b69fae20e5a
Author: Martin Jambor
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68930
--- Comment #10 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:d073e2d75d9ed492de9a8dc6970e5b69fae20e5a
commit r14-3226-gd073e2d75d9ed492de9a8dc6970e5b69fae20e5a
Author: Martin Jambor
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111023
--- Comment #1 from Uroš Bizjak ---
(In reply to Richard Biener from comment #0)
> We could vectorize gcc.dg/vect/pr65947-7.c if we implement the
> extendv4siv4hi pattern (sign-extend V4HI to V4SI). We can already do
> vec_unpacks_lo via
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110677
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 110677, which changed state.
Bug 110677 Summary: UBSAN error: load of value 1818451807, which is not a valid
value for type 'expr_t' when compiling pr49213.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110959
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110959
--- Comment #2 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:4acce4c4e53ae93ab8e7dad2ca9099e45559a541
commit r14-3225-g4acce4c4e53ae93ab8e7dad2ca9099e45559a541
Author: Iain Buclaw
Date: Tue A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110677
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:84e122c34834d9dea189c10fe0bf60c4d1a99fae
commit r14-3224-g84e122c34834d9dea189c10fe0bf60c4d1a99fae
Author: Martin Jambor
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110959
--- Comment #1 from CVS Commits ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:3cf5a511e253876279462b1de08cfd8f5f804242
commit r12-9817-g3cf5a511e253876279462b1de08cfd8f5f804242
Author: Iain Buclaw
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111028
--- Comment #4 from Patrick Palka ---
Or simply just:
diff --git a/111028.C b/111028.C
index ed4106e..85f1c2a 100644
--- a/111028.C
+++ b/111028.C
@@ -15,7 +15,7 @@ class list_t
public:
list_t() { _head.next = _head.prev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111028
--- Comment #3 from Patrick Palka ---
Converting _node_offset from a pointer into an integer offset seems to fix the
testcase:
diff --git a/111028.C b/111028.C
index ed4106e..ef2b1be 100644
--- a/111028.C
+++ b/111028.C
@@ -15,7 +15,7 @@ class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111028
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111020
Jorn Wolfgang Rennecke changed:
What|Removed |Added
CC||amylaar at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109815
--- Comment #3 from C. Heide ---
I finally got access to an AIX 7.2 system and the problem does not occur there
with GCC 12.3, so it seems to be something specific to DWARF only being
partially supported in AIX 7.1.
The installation instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111030
Bug ID: 111030
Summary: tree-object-size: incorrect sub-object size for VLA
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110989
--- Comment #5 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:0618adfa80fcd2fd7ae03b30553c60a6b1abf573
commit r14-3222-g0618adfa80fcd2fd7ae03b30553c60a6b1abf573
Author: Juzhe-Zhong
Date: Sat Aug 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111025
--- Comment #2 from Richard Biener ---
Note GCC already handles this internally (posix_memalign, that is) as if a
malloc attribute was possible and present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111025
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111028
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111029
Bug ID: 111029
Summary: bpf: GCC generates invalid instructions wN = (s8) rM
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111027
Richard Biener changed:
What|Removed |Added
Keywords||build
--- Comment #1 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019
--- Comment #3 from rguenther at suse dot de ---
On Tue, 15 Aug 2023, ppalka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019
>
> Patrick Palka changed:
>
>What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110923
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110940
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106604
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Target Mile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109021
--- Comment #4 from Martin Uecker ---
Sorry, how can an enhancement request that addresses a real C/C++ compatibility
problem be marked "resolved invalid" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110971
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 110988, which changed state.
Bug 110988 Summary: [14 regression] ICE when building 523.xalancbmk_r with pgo
and lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110988
What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110988
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109068
Jose E. Marchesi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111028
Bug ID: 111028
Summary: Incorrect optimization with -o1,-o2
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111026
zhaiqiming at baidu dot com changed:
What|Removed |Added
Resolution|--- |INVALID
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111026
--- Comment #3 from zhaiqiming at baidu dot com ---
[head file]
#include
#include
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111026
--- Comment #2 from zhaiqiming at baidu dot com ---
(In reply to zhaiqiming from comment #1)
> ==
>
> [summary]
>
> When I upgraded from gcc82 to gcc12, I found that linked_list_t::del
> execution did not meet expectations.
> Looking at .s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111026
--- Comment #1 from zhaiqiming at baidu dot com ---
==
[summary]
When I upgraded from gcc82 to gcc12, I found that linked_list_t::del execution
did not meet expectations.
Looking at .s , i noticed that the assembly statements corresponding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #17 from Hans-Peter Nilsson ---
(In reply to Richard Biener from comment #12)
> I think a "too broad" dependence isn't bad. The cris specific solution also
> looks manageable, though I wonder what's special about x-protos.h, knowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #16 from CVS Commits ---
The master branch has been updated by Hans-Peter Nilsson :
https://gcc.gnu.org/g:eef192b181b8777d708671e2541896e7e31293aa
commit r14-3218-geef192b181b8777d708671e2541896e7e31293aa
Author: Hans-Peter Nilsson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111027
Bug ID: 111027
Summary: Install error "tmp-header-vars: Permission denied",
build on NFS, improvement possible
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111026
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111026
Bug ID: 111026
Summary: Incorrect optimization with -o2,-o
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #12 from nsz at gcc dot gnu.org ---
(In reply to Jiangning Liu from comment #11)
> Hi Wilco,
>
> > "it means we will need a linker optimization to remove those redundant BTIs
> > (eg. by changing them into NOPs)"
>
> It will be onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111025
Bug ID: 111025
Summary: attribute((malloc)) and posix_memalign() (and other
functions that return newly allocated object address
into an output parameter)
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110963
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110963
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4d6132e59327e809a4d4e39fb9465dbd43775b7c
commit r14-3217-g4d6132e59327e809a4d4e39fb9465dbd43775b7c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #40 from Mikael Morin ---
Harald, I have just closed the followup PR110419.
I think this PR can be closed as well, or is there something left to be done?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110991
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110991
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:bcdbedb3e6083ad01d844ed97cf19645c1ef6568
commit r14-3216-gbcdbedb3e6083ad01d844ed97cf19645c1ef6568
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
Richard Biener changed:
What|Removed |Added
Keywords||build
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.4
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111024
Bug ID: 111024
Summary: libgomp: FAILs with oldish libnuma/libmemkind
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #15 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:ecb95399f43873e1f34119ac260bbea2ef358e53
commit r14-3215-gecb95399f43873e1f34119ac260bbea2ef358e53
Author: Kewen Lin
Date: Tue Aug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111023
Bug ID: 111023
Summary: missing extendv4siv4hi (and friends)
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #14 from Kewen Lin ---
(In reply to Kewen Lin from comment #13)
> (In reply to Richard Biener from comment #12)
> > I think a "too broad" dependence isn't bad. The cris specific solution also
> > looks manageable, though I wonder wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #13 from Kewen Lin ---
(In reply to Richard Biener from comment #12)
> I think a "too broad" dependence isn't bad. The cris specific solution also
> looks manageable, though I wonder what's special about x-protos.h, knowing
> very l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #12 from Richard Biener ---
I think a "too broad" dependence isn't bad. The cris specific solution also
looks manageable, though I wonder what's special about x-protos.h, knowing very
little of that area.
95 matches
Mail list logo
