//binary-trunk-r14-6818-20231224094952-gbd901d76734-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231224 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #14 from Hans-Peter Nilsson ---
(In reply to GCC Commits from comment #9)
> The master branch has been updated by Hans-Peter Nilsson :
>
> https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0
>
> commit r14-6817-g3d03630b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113127
Bug ID: 113127
Summary: Unexpected error: '' was not declared
'constexpr'
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #17 from Roger Sayle ---
I think this patch might resolve the problem (or move it somewhere else):
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 9fef2bf6585..218bca905f5 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -6274,10 +6274,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #18 from Roger Sayle ---
Please ignore comment #17, the above patch is completely bogus/broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761
--- Comment #6 from Jonathan Wakely ---
OK that's great, thanks for clarifying. (I haven't looked at the impl on
godbolt yet, sorry)
This mailing list is for automated emails from our bug database, not
for reporting bugs directly.
See https://gcc.gnu.org/bugs/ for how to report bugs, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #5 from Jonathan Wakely ---
I'm not sure what you mean by "the compiler is free to generate code that takes
it into account." Takes what into account? What problem does that freedom
cause?
The locale facet instantiations are compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #6 from Jonathan Wakely ---
(In reply to andysem from comment #3)
> I think, a failing dynamic_cast would not be useful as this would make
> std::use_facet unusable with -fno-rtti.
I don't see a problem with that. If you want to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #7 from Peter Dimov ---
You don't necessarily need dynamic_cast because facets are always installed and
obtained by their exact type, not via a reference to base. You can store the
Facet* as given (like shared_ptr does), and return i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111485
--- Comment #4 from GCC Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:f24d6f0031fd515e6497c8c96446afd02aa4dbaa
commit r12-10068-gf24d6f0031fd515e6497c8c96446afd02aa4dbaa
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111485
--- Comment #5 from GCC Commits ---
The releases/gcc-11 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:84cab505d69038647d98f9340559fc941446e479
commit r11-11168-g84cab505d69038647d98f9340559fc941446e479
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #8 from Jonathan Wakely ---
(In reply to Peter Dimov from comment #7)
> You don't necessarily need dynamic_cast because facets are always installed
> and obtained by their exact type, not via a reference to base.
Is that true? std::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Peter Dimov from comment #7)
> > You don't necessarily need dynamic_cast because facets are always installed
> > and obtained by their exact typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #10 from Peter Dimov ---
Maybe the right thing to do is to use dynamic_cast only for virtual inheritance
(either have a trait or check whether static_cast isn't a valid expression),
otherwise static_cast, in both cases (standard and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #19 from Roger Sayle ---
Created attachment 56930
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56930&action=edit
proposed patch
And now for a patch that does (or should) work. This even contains an
optimization, we middle-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113127
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #11 from andysem at mail dot ru ---
> I'm not sure what you mean by "the compiler is free to generate code that
> takes it into account." Takes what into account? What problem does that
> freedom cause?
I mean the compiler could mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128
Bug ID: 113128
Summary: Wrong implied-do with optimizations
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
Bug ID: 113129
Summary: "using declaration" not detected as "exported" in
exported namespace
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-12-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
--- Comment #2 from Larry Smith ---
@Andrew Thanks for the feedback. I don't work in Unix-like environments though
normally (including Linux) so CMake, make, and shell commands are something I
rarely work with (I specialize on Microsoft platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-12-24
Known to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128
Igor S Gerasimov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111837
Andrew Pinski changed:
What|Removed |Added
CC||gigor-ads at yandex dot ru
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113128
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #3 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113130
Bug ID: 113130
Summary: `abs(a) == b` could be expanded as `(a == b || a ==
-b)`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #20 from YunQiang Su ---
This patch has 2 problems:
1. We may need some more steps to add
gcc_assert (outprec < inprec)
Now, I met some ICE with it.
2. It doesn't solve the this problem:
In combine.cc, jump_insn eats trunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99930
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|middle-end
--- Comment #11 from Andrew P
Thanks for the tip!
2023年12月24日(日) 23:35 Jonathan Wakely :
> This mailing list is for automated emails from our bug database, not
> for reporting bugs directly.
>
> See https://gcc.gnu.org/bugs/ for how to report bugs, thanks.
>
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #21 from YunQiang Su ---
Sorry, Roger. Your patch is correct.
I misunderstood it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #22 from YunQiang Su ---
Any way, we should split the assert to another patch.
I will try to find all the wrongly used TRULY_NOOP_TRUNCATION_MODES_P.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #26 from JuzheZhong ---
CC Li Pan who may also reproduce the bugs for me.
Plz give us more details how to reproduce the bugs since we don't see any bugs
when build and run SPEC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #11 from Lipeng Zhu ---
(In reply to Jakub Jelinek from comment #10)
>For what I can reproduce on my box (rwlock_1.exe built in the
>x86_64-pc-linux-gnu/libgomp/testsuite subdirectory using the -O0
>compilation line from libgomp*/*.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19832
--- Comment #14 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:59ecd5ff096f800de17b804f1482055f2d84d629
commit r14-6827-g59ecd5ff096f800de17b804f1482055f2d84d629
Author: Andrew Pinski
Date: Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #12 from Lipeng Zhu ---
(In reply to Lipeng Zhu from comment #9)
> Since I still can't reproduce the failure on my side :(, just curious, will
> the new added 'rwlock' test cases failed on mutex lock?
OK, I rerun these rwlock* test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113131
Bug ID: 113131
Summary: `((A&B)^C)|B` should be simplified to `C | B`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113131
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-12-25
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #13 from Lipeng Zhu ---
OK, I think I find the root cause of this error, when thread number greater
than 1000, the file_name = 1000_tst.dat, character(11) will overflow. This will
generate the same file_name like ***_tst.dat.
diff
41 matches
Mail list logo
