https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113667
Richard Biener changed:
What|Removed |Added
Keywords||ABI
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113668
Richard Biener changed:
What|Removed |Added
Keywords||ABI
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113669
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-01-31
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113670
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #14 from JuzheZhong ---
Thanks Richard.
It seems that we can't fix this issue for now. Is that right ?
If I understand correctly, do you mean we should wait after SLP representations
are finished and then revisit this PR?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #15 from rguenther at suse dot de ---
On Wed, 31 Jan 2024, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
>
> --- Comment #14 from JuzheZhong ---
> Thanks Richard.
>
> It seems that we can'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113672
Richard Biener changed:
What|Removed |Added
Keywords||testsuite-fail
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113673
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #2 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113676
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Summary|[11/12 R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #16 from JuzheZhong ---
(In reply to rguent...@suse.de from comment #15)
> On Wed, 31 Jan 2024, juzhe.zhong at rivai dot ai wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
> >
> > --- Comment #14 from JuzheZhong ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113677
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-01-31
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #23 from Robin Dapp ---
> this is:
>
> _429 = mask_patt_205.47_276[i] ? vect_cst__262[i] : (vect_cst__262 <<
> {0,..})[i];
> vect_iftmp.55_287 = mask_patt_209.54_286[i] ? _429 [i] : vect_cst__262[i]
But isn't it rather
_429 = mask_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113678
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-01-31
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
Bug ID: 113679
Summary: long long minus double with gcc -m32 produces
different results than other compilers or gcc -m64
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
Andrew Pinski changed:
What|Removed |Added
Component|c |target
--- Comment #1 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
--- Comment #2 from Дилян Палаузов ---
This happens only without optimizations:
$ gcc -O0 -m32 -o diff diff.c && ./diff
-2.00
$ gcc -O1 -m32 -o diff diff.c && ./diff
0.00
$ gcc -O2 -m32 -o diff diff.c && ./diff
0.00
$ gcc -O3 -m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
Andrew Pinski changed:
What|Removed |Added
CC||dilyan.palauzov at aegee dot
org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
--- Comment #4 from Jakub Jelinek ---
Yeah, it is, that is how excess precision behaves.
Due to the cast applying just to l rather than l - d it returns 0.0 with
-fexcess-precision=standard, but if you change it to (double)(l - d) then it
will r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #17 from rguenther at suse dot de ---
On Wed, 31 Jan 2024, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
>
> --- Comment #16 from JuzheZhong ---
> (In reply to rguent...@suse.de from commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113670
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:924137b9012cee5603482242de08fbf0b2030f6a
commit r14-8645-g924137b9012cee5603482242de08fbf0b2030f6a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113676
--- Comment #2 from Magnus Hokland Hegdahl ---
Hi, here's a version that doesn't need -std=c++20 or argv:
https://godbolt.org/z/Y9ooY998e
#include
constexpr auto bit_ceil(unsigned x) -> unsigned {
if (x <= 1) return 1U;
int w = 32 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113670
Richard Biener changed:
What|Removed |Added
Known to fail|14.0|
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #18 from JuzheZhong ---
(In reply to rguent...@suse.de from comment #17)
> On Wed, 31 Jan 2024, juzhe.zhong at rivai dot ai wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
> >
> > --- Comment #16 from JuzheZhong ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113633
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #1 from L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113676
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113676
--- Comment #4 from Jakub Jelinek ---
And with --param=vrp1-mode=vrp it segfaulted even with
r13-4276-gce917b0422c145779b83e005afd8433c0c86fb06 but the next revision
removed that parameter, so can't go further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
--- Comment #8 from Richard Biener ---
OK, so the issue is that we're recording the IPA result with the wrong VUSE
since we're calling vn_reference_lookup_2 with !data->last_vuse_ptr but
data->finish (vr->set, vr->base_set, v) inserts a hashtabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #19 from rguenther at suse dot de ---
On Wed, 31 Jan 2024, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
>
> --- Comment #18 from JuzheZhong ---
> (In reply to rguent...@suse.de from commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113637
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:457d2b59b58e5998e1e6967316d4e3e8f24edeed
commit r14-8651-g457d2b59b58e5998e1e6967316d4e3e8f24edeed
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113639
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:90ac839a470d61ffcd9eee0d7d37ca9c385dfefb
commit r14-8650-g90ac839a470d61ffcd9eee0d7d37ca9c385dfefb
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
--- Comment #5 from Дилян Палаузов ---
gcc -m64 -fexcess-precision=fast -o diff diff.c && ./diff
0.00
gcc -m32 -fexcess-precision=fast -o diff diff.c && ./diff
-2.00
clang -m32 -fexcess-precision=fast -o diff diff.c && ./diff
0.00
cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
--- Comment #6 from Andrew Pinski ---
Because 64bit uses the SSE2 fp instructions rather than x87 fp instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b59775b642bb2b1ecd2e6d52c988b9c432117bc8
commit r14-8652-gb59775b642bb2b1ecd2e6d52c988b9c432117bc8
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2024-01-24 00:00:00 |2019-04-29 0:00
--- Comment #4 from Jo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
Jonathan Wakely changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113639
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113637
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656
--- Comment #8 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
--- Comment #3 from Xi Ruoyao ---
It seems no longer happening with current trunk. Let me do a bisection...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> The best fix would likely be to pre-insert all the IPA-CP known constants
> instead of trying to discover them "late".
>
> I'm testing the easy fix for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
--- Comment #10 from Richard Biener ---
Hmm, I have another fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630
--- Comment #6 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:724b64304ff5c8ac08a913509afd6fde38d7b767
commit r14-8653-g724b64304ff5c8ac08a913509afd6fde38d7b767
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Summary|[11/12/13/14 Reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #19 from JuzheZhong ---
The loop is:
bb 3 -> bb 4 -> bb 5
| |__⬆
|__⬆
The condition in bb 3 is if (i_21 == 1001).
The condition in bb 4 is if (N_13(D) > i_18).
Look into lsplit:
This loop doesn't satisfy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #1 from Jonathan Wakely ---
Maybe something like this:
diff --git a/libstdc++-v3/config/os/gnu-linux/os_defines.h
b/libstdc++-v3/config/os/gnu-linux/os_defines.h
index 0af29325388..f7c73560831 100644
--- a/libstdc++-v3/config/os/gnu-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #20 from Richard Biener ---
I think we want split_loop () handle this case. That means extending it to
handle loops with multiple exits. OTOH after loop rotation to
if (i_21 == 1001)
goto ; [1.00%]
else
goto ; [99.00%]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> +// Since glibc 2.34 using -D_TIME_BITS=64 will enable 64-bit time_t
> +// for "legacy ABIs", i.e. ones that historically used 32-bit time_t.
> +// This inter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
--- Comment #6 from Jonathan Wakely ---
Some of the tests FAIL for different reasons:
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algo.h:2051:
In function:
_FIter std::upper_bound(_FIter, _FIter, const _Tp&,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680
Bug ID: 113680
Summary: Missed optimization: Redundant cmp/test instructions
when comparing (x - y) > 0
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680
Richard Biener changed:
What|Removed |Added
Component|rtl-optimization|middle-end
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
--- Comment #11 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:cfb3f666562fb4ab896a05c234a697afb63627a4
commit r14-8655-gcfb3f666562fb4ab896a05c234a697afb63627a4
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680
--- Comment #2 from Kang-Che Sung ---
I forgot to mention that such optimization is unsafe for floating points
(actually I knew that when I write my code). `(a - b) < 0` optimization
shouldn't be performed with unsigned integers either. I reques
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
--- Comment #7 from Jonathan Wakely ---
__pstl::__tbb_backend::__merge_func::split_merging (which should be a reserved
name) does:
if (__nx < __ny)
{
__ym = _M_ys + __ny / 2;
if (_x_orig)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
--- Comment #8 from Jonathan Wakely ---
https://github.com/llvm/llvm-project/issues/80136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111627
--- Comment #2 from Gaius Mulley ---
Created attachment 57267
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57267&action=edit
Proposed fix
Here is a proposed patch, the problem was fixed by renaming conflicting
testnames. There were som
enable-languages=c,c++,fortran,lto --disable-multilib --disable-libsanitizer
--enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240131 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
--- Comment #9 from Richard Biener ---
With all VARYING we simplify
i_19 = (int) _2;
_6 = (int) _5;
Value numbering stmt = _7 = _6 <= i_19;
Applying pattern match.pd:6775, gimple-match-4.cc:1795
Match-and-simplified _6 <= i_19 to 1
where _5 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682
Bug ID: 113682
Summary: Branches in branchless binary search rather than
cmov/csel/csinc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113509
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #26 from GCC Commits ---
The master branch has been updated by Alex Coplan :
https://gcc.gnu.org/g:0529ba8168c89f24314e8750237d77bb132bea9c
commit r14-8657-g0529ba8168c89f24314e8750237d77bb132bea9c
Author: Alex Coplan
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Alex Coplan changed:
What|Removed |Added
Summary|[12/13/14 Regression] |[12/13 Regression]
|dar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #4 from Mikael Pettersson ---
Confirmed:
04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a is the first new commit
commit 04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a
Author: Manolis Tsamis
Date: Mon Oct 16 13:08:12 2023 -0600
Implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113681
Richard Biener changed:
What|Removed |Added
Keywords||error-recovery
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113681
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92444
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
--- Comment #8 from Дилян Палаузов ---
-fexcess-precision=standard does not ensure consistent behaviour between gcc
13.2.1 20231205 (Red Hat 13.2.1-6) and clang 17.0.5. -msse2 -mfpmath=sse does
for diff.c:
#include
#include
int main(void) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113611
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113546
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113641
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
--- Comment #9 from Jakub Jelinek ---
That is not what I read from what you've posted, -fexcess-precision=standard is
consistent between the compilers, -fexcess-precision=fast is not (and doesn't
have to be), neither between different compilers,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
--- Comment #10 from Jakub Jelinek ---
Oh, you mean the pow equality comparison. I think you should study something
about floating point, errors, why equality comparisons of floating point values
are usually a bad idea etc.
There is no gcc bug,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113646
--- Comment #3 from Martin Jambor ---
(In reply to Richard Biener from comment #1)
> Did you try with -fprofile-partial-training (is that default on? it
> probably should ...). Can you please try training with the rate data
> instead of train
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
--- Comment #10 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:22dbfbe8767ff4c1d93e39f68ec7c2d5b1358beb
commit r14-8658-g22dbfbe8767ff4c1d93e39f68ec7c2d5b1358beb
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113672
Lewis Hyatt changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
--- Comment #9 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:a73421bcf301911f2cbdb1c58316ddf3473ea6d5
commit r14-8659-ga73421bcf301911f2cbdb1c58316ddf3473ea6d5
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
Richard Biener changed:
What|Removed |Added
Known to work||14.0
Summary|[11/12/13/14 R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
Lewis Hyatt changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
--- Comment #10 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:0debaceb11dee9781f9a8b320cb5893836324878
commit r14-8660-g0debaceb11dee9781f9a8b320cb5893836324878
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
--- Comment #11 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:0a640455928a050315f6addd88ace5d945eba130
commit r14-8661-g0a640455928a050315f6addd88ace5d945eba130
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113502
--- Comment #2 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:f7935beef7b02fbba0adf33fb2ba5c0a27d7e9ff
commit r14-8662-gf7935beef7b02fbba0adf33fb2ba5c0a27d7e9ff
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113502
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737
--- Comment #5 from Patrick Palka ---
Reduced:
$ cat 112737.h
template class _Cont>
using _DeduceExpr1 = decltype(_Cont{});
$ cat 112737_a.H
#include "112737.h"
$ cat 112737_b.C
import "112737_a.H";
#include "112737.h"
$ g++ -fmodules-ts 112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106052
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680
--- Comment #3 from Kang-Che Sung ---
Oops. I made a typo in the test code. func4() shouldn't have that redundant
brace.
The corrected example:
```
void func4(int x, int y) {
int diff = x - y;
if (diff > 0)
putchar('>');
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113683
Bug ID: 113683
Summary: explicit template instantiation wrongly checks private
base class accessibility
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737
--- Comment #6 from Patrick Palka ---
Ah, this seems to be a general declaration matching issue not specific to
modules. Here's a non-modules testcase:
template class TT, class T>
decltype(TT{T()}) f(); // #1
template class TT, class T>
declt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111627
--- Comment #3 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:4fd094835a8997cdcc3d18d7d297debe1527202d
commit r14-8663-g4fd094835a8997cdcc3d18d7d297debe1527202d
Author: Gaius Mulley
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
--- Comment #11 from Jakub Jelinek ---
Anyway, seems clang is buggy:
clang -O2 -m32 -mno-sse -mfpmath=387 -fexcess-precision=standard
#include
int
main ()
{
#if FLT_EVAL_METHOD == 2 && LDBL_MANT_DIG == 64 && DBL_MANT_DIG == 53
if ((double) 1
1 - 100 of 187 matches
Mail list logo
