https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
Martin Liška changed:
What|Removed |Added
Summary|false positive |[12 Regression] false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108390
Martin Liška changed:
What|Removed |Added
Summary|ICE in fold_convert_loc, at |ICE in fold_convert_loc, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.3
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
--- Comment #5 from Richard Biener ---
[E]VRP testcase which shows the odd 'off' range on the false edge:
void bar(char *);
void foo (char *p, char *pp, int off)
{
char *q = p + off;
if (q != p)
bar (q);
char *qq = pp + off;
if (qq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108390
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Miles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144
--- Comment #4 from Martin Liška ---
May I please ping this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
--- Comment #6 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> [E]VRP testcase which shows the odd 'off' range on the false edge:
>
> void bar(char *);
>
> void foo (char *p, char *pp, int off)
> {
> char *q = p + off;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
--- Comment #6 from Martin Liška ---
(In reply to Andrew Pinski from comment #5)
> It might be the case the object files were unused in the archive so they are
> not linked in the LTO front-end but now with using LTO partial linking, they
> are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
Bug ID: 108391
Summary: Operator '::operator delete(void*, size_t)' was not
found when clang compiled stdlibc++
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108387
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:adbee4a197c7b735a3dd58cfac8933f70069f71d
commit r13-5136-gadbee4a197c7b735a3dd58cfac8933f70069f71d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108387
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107209
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:3893c9c0a16832f55d8d0827f50c48a56c52f6e7
commit r13-5137-g3893c9c0a16832f55d8d0827f50c48a56c52f6e7
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107209
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resoluti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:add71b95dd27d73d64eee0a9c8f748672b7050f5
commit r13-5139-gadd71b95dd27d73d64eee0a9c8f748672b7050f5
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107719
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #14 from Bill Zissimopoulos ---
(In reply to niXman from comment #13)
> I figured out the building problem.
>
> it seems to work as it should for symlink, but it doesn't work for hardlink.
This is good news.
Unless I misunderstand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #15 from niXman ---
> There is no way to resolve a hardlink to a "real" path, all hardlinked paths
> are "real".
according to this link:
https://stackoverflow.com/questions/10260676/programmatically-finding-the-target-of-a-windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #16 from niXman ---
Created attachment 54264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54264&action=edit
patch
the patch for `lrealpath()` for win32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #17 from Bill Zissimopoulos ---
(In reply to niXman from comment #15)
> > There is no way to resolve a hardlink to a "real" path, all hardlinked
> > paths are "real".
>
> according to this link:
> https://stackoverflow.com/question
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #18 from Bill Zissimopoulos ---
(In reply to niXman from comment #16)
> Created attachment 54264 [details]
> patch
>
> the patch for `lrealpath()` for win32.
Thanks for patch. Looking at it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424
--- Comment #4 from Tobias Burnus ---
Created attachment 54265
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54265&action=edit
WIP patch (with one WIP testcase)
This patch should address the issues of this PR reported so far.
But there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424
--- Comment #5 from Tobias Burnus ---
For completeness, the C testcase to previous comment (comment 3) is as follows.
Contrary to Fortran, I put a 'lastprivate' to all variables – to match the
current
patch (→ see (A) in comment 3).
int n,m,p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #19 from Bill Zissimopoulos ---
Comment on attachment 54264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54264
patch
Many thanks for the patch. Please consider the following:
LINES 144-152:
I would change the CreateFile ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424
--- Comment #6 from Jakub Jelinek ---
I think there are multiple issues. For the do i = 1, 9, 1 case, the bug is
that we:
gfc_init_se (&se, NULL);
gfc_conv_expr_val (&se, code->ext.iterator->end);
gfc_add_block_to_block (pbloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #36 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:426a9f5570d74040176f81e7cf6806b36ebc907f
commit r13-5141-g426a9f5570d74040176f81e7cf6806b36ebc907f
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #35 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0bf7131e539de4ca66b3c0eb72aa0afbd8f006dc
commit r13-5140-g0bf7131e539de4ca66b3c0eb72aa0afbd8f006dc
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #20 from Bill Zissimopoulos ---
Regarding LINE 192:
I would add that if somehow the path returned by GetFinalPathNameByHandle does
not conform to the \\?\X: or \\?\UNC\ pattern I would fall back to
GetFullPathName.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107129
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #3 from Ri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107396
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
--- Comment #21 from Richard Biener ---
I think this is WONTFIX on the GCC side? Maybe changes.html or porting_to.html
should mention this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424
Tobias Burnus changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #7 from Tob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107467
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2022-10-30 00:00:00 |2023-1-13
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #11 from Ben Brewer ---
So I was using "-x f77" which I would expect to instruct the compiler to run in
a mode compatible with Fortran 77, it seems non-intuitive to have to enable
-std=legacy to compile the very tests which define f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424
--- Comment #8 from Jakub Jelinek ---
For the non-simple loops, I guess the questions are if
do i = x, y, 1
is equivalent to
for (i = x; i <= y; i += 1)
or not (especially regarding the in C UB cases of y being above INT_MAX -
1),
an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107475
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107516
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #3 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107129
--- Comment #4 from Martin Liška ---
(In reply to Richard Biener from comment #3)
> We no longer warn, not sure what fixed it?
r13-4598-gf8d136e50e6f82cb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107516
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #4 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107129
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 107129, which changed state.
Bug 107129 Summary: [13 Regression] False positive -Wstringop-overflow warning
with -O2 or -O3 since r13-137-gee1cb43bc76de800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107129
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107558
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108197
--- Comment #3 from Richard Biener ---
(In reply to Stephen from comment #2)
> Richard, are you saying this a bug in the boost code? It's not quite clear
> to me from your message. Can you be more specific about what the bug is in
> that case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108274
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #1 from Jonathan Wakely ---
(In reply to jinci kang from comment #0)
> * The reason is that clang does not define the macro
> __cpp_sized_deallocation.
Well then that's a clang bug. It shouldn't be trying to use sized delete if it
h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
--- Comment #11 from Mark Rutland ---
Further, at `-O1` and above GCC seems to silently drop the alignment of any
implementation of abort(), apparently implicitly marking it as cold.
I assume that may be true for other special functions.
For ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #2 from Jonathan Wakely ---
Oh clang isn't using it, you're using it explicitly. So then that's a bug in
your code. You shouldn't use it unless the macro is defined to say that it's
usable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108344
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
To gather more information, I've tried a -g3 -O0 build. The failures
still occur, but the failure mode is slightly different: all the 64-bit
tests in gm2/iso/pass now SEGV in cc1gm2:
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #3 from jinci kang ---
(In reply to Jonathan Wakely from comment #2)
> Oh clang isn't using it, you're using it explicitly. So then that's a bug in
> your code. You shouldn't use it unless the macro is defined to say that it's
> usab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383
--- Comment #3 from eebssk1 at godaftwithebk dot pub ---
Exactly same problem with -Os on lto.(Seems reflect the problem in that github
issue)
The project seems only supports mingw target.
I'll get back when have more information.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108377
--- Comment #4 from Thomas Schwinge ---
Thanks, Andrew, for looking into this.
(In reply to Andrew Pinski from comment #2)
> If calc_n(259) returns (__SIZE_TYPE__)-1 (aka 18446744073709551615) [...]
> the warning is correct ([...]) in some sens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #5 from jinci kang ---
(In reply to Jakub Jelinek from comment #4)
> No, but:
> #include
>
> int main() {
> void* p = ::operator new[](2);
> #if __cpp_sized_deallocation >= 201309
> ::operator delete[](p, 2);
> #else
> ::oper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #29 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #27)
> "elide an overflow" should be probably "elide an overflow or division by
> zero" I think,
> because finite / 0.0 returns infinity and raises FE_DIVBYZERO rath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383
--- Comment #4 from eebssk1 at godaftwithebk dot pub ---
The problem occurs at final linking.
x86_64-w64-mingw32-g++ -o src/dxgi/dxgi.dll src/dxgi/dxgi.dll.p/version.o
src/dxgi/dxgi.dll.p/dxgi_adapter.cpp.obj src/dxgi/dxgi.dll.p/dxgi_enums.cpp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108392
Bug ID: 108392
Summary: Unexpected optimization in presence of
'__attribute__((noipa))'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
Aldy Hernandez changed:
What|Removed |Added
Attachment #54253|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #7 from Jakub Jelinek ---
Grep shows that clang predefines that macro if -fsized-deallocation is used.
But why that option doesn't default to on for C++14 is hard to understand.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:e2fc12a5dafadf15d804e1d2541528296e97a847
commit r13-5143-ge2fc12a5dafadf15d804e1d2541528296e97a847
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86419
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:02dab998665dda0f6df31740e8897c42de3d740f
commit r13-5144-g02dab998665dda0f6df31740e8897c42de3d740f
Author: Dimitrij Mijoski
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #8 from jinci kang ---
(In reply to Jakub Jelinek from comment #7)
> Grep shows that clang predefines that macro if -fsized-deallocation is used.
> But why that option doesn't default to on for C++14 is hard to understand.
Clang has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86419
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #9 from jinci kang ---
This issue can be closed, but I don't know how to close this, can you help me
to close it.Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #10 from Jonathan Wakely ---
I've already closed it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #11 from jinci kang ---
OK
redi at gcc dot gnu.org 于2023年1月13日周五 21:53写道：
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
>
> --- Comment #10 from Jonathan Wakely ---
> I've already closed it
>
> --
> You are receiving this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393
Bug ID: 108393
Summary: circular concept false-positive
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131
--- Comment #7 from Jakub Jelinek ---
If I change the testcase to:
/* PR target/107131 */
/* { dg-do run } */
/* { dg-options "-Os -fno-ipa-vrp -fno-tree-bit-ccp -Wno-psabi" } */
typedef unsigned char C;
typedef unsigned long long __attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108392
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #12 from Jonathan Wakely ---
(In reply to jinci kang from comment #8)
> Clang has a problem with ABI breaking.
> https://reviews.llvm.org/D8467
Ah yes. The most recent attempt to fix it is at:
https://reviews.llvm.org/D112921
/aarch64/cpunative/native_cpu_18.c scan-assembler \\.arch
armv8.6-a\\+crc\\+fp16\\+aes\\+sha3\\+rng
=== gcc Summary ===
# of expected passes1
# of unexpected failures1
/home/polacek/x/trunk/gcc/xgcc version 12.2.1 20230113 (GCC)
# GCC_CPUINFO=info_18 gcc -mcpu
-but-set-variable.
Using version `13.0.0 20230113 (experimental)'.
# echo 'int f() { constexpr int v = 0; return v; }' | gcc -c -xc -std=c2x -Wall
-Wextra -
: In function 'f':
:1:25: warning: variable 'v' set but not used
[-Wunused-but-set-variable]
As a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #12 from Steve Kargl ---
On Fri, Jan 13, 2023 at 11:49:44AM +, ben.brewer at codethink dot co.uk
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
>
> --- Comment #11 from Ben Brewer ---
> So I was using "-x f77" whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #13 from jinci kang ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to jinci kang from comment #8)
> > Clang has a problem with ABI breaking.
> > https://reviews.llvm.org/D8467
>
> Ah yes. The most recent attempt to f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393
--- Comment #1 from Jonathan Wakely ---
The concept C checks whether S satisfies the constraint
for the iterator_traits specialization. That performs ADL for operator== with
S and unreachable_sentinel_t as associated classes.
That finds the hidd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393
--- Comment #2 from Jonathan Wakely ---
Specifically, ADL for __t == __u finds this function:
template
friend constexpr bool operator==(unreachable_sentinel_t, const _Iter&)
noexcept;
making it an overload resolution candidate. It's not vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
Bug ID: 108396
Summary: PPCLE: vec_vsubcuq missing
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:254cf9552ffb1693f0bc74f6d25601dafafbc144
commit r13-5150-g254cf9552ffb1693f0bc74f6d25601dafafbc144
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] wrong |[11/12 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108397
Bug ID: 108397
Summary: Missed optimization with [0, 0][-1U,-1U] range
arithmetics
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
--- Comment #8 from Vincent Lefèvre ---
Isn't it the same as PR56020, which is due to the fact that the STDC
FENV_ACCESS pragma is not implemented and assumed to be OFF (PR34678)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #19 from Jan Dubiec ---
(In reply to Jonathan Wakely from comment #17)
> (but I still get the assembler errors for h8300-elf using
> latest binutils).
This is strange. I have just successfully built binutils edf64cd2 and then gcc
42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #13 from Jerry DeLisle ---
Created attachment 54267
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54267&action=edit
FM509 that I have here.
This morning I also recall there was one NIST test that had an error. I
contacted the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108285
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3456db4de8940235b303ca38a689353854c9239f
commit r13-5152-g3456db4de8940235b303ca38a689353854c9239f
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108285
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 144 matches
Mail list logo
