https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102755
Duncan Simpson changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102642
Andrew Pinski changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99141
Alexandros Liarokapis changed:
What|Removed |Added
CC||liarokapis.v at gmail dot com
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486
--- Comment #54 from Eric Botcazou ---
> "this" means the problem with C++ exceptions, which indeed is fixed by
> building gcc after reverting to grep 3.0.
>
> The build failure with Ada, which predated the grep upgrade, persists.
>
> Eric: I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102801
Bug ID: 102801
Summary: Incorrect -Wmaybe-uninitialized warning/interation for
a std::optional only when a nested struct is also
present.
Product: gcc
Version: 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102798
--- Comment #9 from H.J. Lu ---
Created attachment 51618
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51618&action=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486
--- Comment #55 from Óscar Fuentes ---
Here we go (this is a debug build):
$
/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc
-B/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102802
Bug ID: 102802
Summary: Selection of inherited operator contrary to `using`
clause in C++
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803
Bug ID: 102803
Summary: Bug: -no-canonical-prefixes not working
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: drive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102801
--- Comment #1 from Jonathan Wakely ---
7, 8, 9 and 10 all warn:
mozilla_jwakely0/warn3.cpp: In function 'void foo(Q&, std::vector&)':
mozilla_jwakely0/warn3.cpp:8:7: warning: '.C::b' may be used
uninitialized in this function [-Wmaybe-uninitia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102798
H.J. Lu changed:
What|Removed |Added
Attachment #51618|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102716
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:d97dbf60dda22e0668dc33ca3a536adcb0963a65
commit r11-9159-gd97dbf60dda22e0668dc33ca3a536adcb0963a65
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803
--- Comment #1 from Andrew Pinski ---
Sounds like Bazel is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102802
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102802
--- Comment #2 from Andrew Pinski ---
ICC also rejects it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102799
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99505
Andrew Pinski changed:
What|Removed |Added
CC||nickhuang99 at hotmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102594
--- Comment #2 from Andrew Pinski ---
Clang, MSVC and ICC all accept this code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787
--- Comment #5 from anlauf at gcc dot gnu.org ---
Looks like an issue with simplification of array within array constructor:
print *, - a
print *, - [a]
print *, - [[a]]
end
-fdump-fortran-original produces:
code:
WRITE UNIT=6 FMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629
Andrew Pinski changed:
What|Removed |Added
Summary|ICE: tree check: expected |[10/11/12 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665
Eric Gallager changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102602
Andrew Pinski changed:
What|Removed |Added
Summary|[10/11/12 Regression] 32bit |32bit mips: Error: branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102602
--- Comment #3 from Andrew Pinski ---
Most likley exposed by r10-9646 which introduced more inlining or rather fixing
an inlining issue which was broken in the GCC 10 series.
This most likely was broken in GCC 9 too.
The function is really just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102801
Eric Gallager changed:
What|Removed |Added
Blocks||24639
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580
--- Comment #3 from Andrew Pinski ---
We can do it for:
int f(int x) {
if (x < 0)
__builtin_abort();
x+=1;
return x/3;
}
expand_expr_divmod has the code already to handle this, just needs a range.
Expand would do querry to get bette
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580
--- Comment #4 from Andrew Pinski ---
For an example GCC does optimize the following too:
int f(int x) {
if (x < 0)
__builtin_unreachable();
return x/3;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102801
--- Comment #3 from Calin Culianu ---
@Eric Gallager : Initially I came across that bug and it looked eerily similar
to this one. I am not a gcc dev, just a user of gcc. No idea.. but yeah looks
like in some situations certainly gcc has trouble
error: enumerated and non-enumerated type in conditional expression
Version: 11.2.0
system: CentOS Linux 7.7.1908 on Intel Xeon
command: g++ -Wall -Wextra -std=c++11 20211017-bug.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803
--- Comment #2 from Carlos Galvez ---
Did you read my detailed explanation and reproducible example? I took great
care and time to make the problem easy to investigate. GCC is not doing what is
supposed to do. Other compilers, like Clang, do act
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804
Andrew Pinski changed:
What|Removed |Added
Summary|template matching fails w/ |template matching fails w/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98950
Jeffrey A. Law changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102618
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:fb5b0778586674c31f69d866038a5b5bd9a151ee
commit r12-4462-gfb5b0778586674c31f69d866038a5b5bd9a151ee
Author: Luís Ferreira
Date: Sun Oc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102805
Bug ID: 102805
Summary: at -O2, spurious stringop-overflow warning writing to
std::vector::back()
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102805
--- Comment #1 from Andrew Pinski ---
Hmm:
[local count: 751619281]:
if (end_8(D) > start_9(D))
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 248034361]:
_2 = end_8(D) - start_9(D);
_3 = _2 + 1;
data ={v} {CLOBBER};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102805
--- Comment #2 from rudick at gmail dot com ---
Interesting.
if (f && end > start && start < 100 && end < 100) {
& I still get the warning though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102805
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804
--- Comment #2 from Jonathan Wakely ---
unsigned int32_t is invalid. You cannot use unsigned (or short or long) with a
typedef, only with 'int'.
GCC was changed to diagnose that fairly recently, which is probably why the
behaviour changed since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804
--- Comment #3 from Jonathan Wakely ---
I think it was pr 84701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427
--- Comment #7 from cqwrteur ---
This is incorrect when we canadian build multilib. unfortunately.
I find this is an issue for not just libstdc++, but libaotmic, libssp etc too.
This script is clearly just not right. It should only copy DLLs fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102806
Bug ID: 102806
Summary: [x86] Suboptimal codegen for v4hi vector concat under
-mavx512bw and -mavx512vl
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102806
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-10-18
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102781
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-10-18
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
--- Comment #5 from Richard Biener ---
Even out-of-line does not help if there are visible CSE/association
opportunities across such call. A workaround is to make the out-of-line
function __attribute__((returns_twice)) which should insert artif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102788
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102793
Richard Biener changed:
What|Removed |Added
Target||aarch64
--- Comment #3 from Richard Bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102798
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767
--- Comment #7 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #6)
> (In reply to Richard Earnshaw from comment #5)
> > We have the type
> > > type > size
> > unit-size
> > and movmisalign pattern is enab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102793
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Biener from comment #3)
> I wonder why tail-merging doesn't do it's job here. It does (on
> x86_64-linux):
Oh I missed that.
> but what's missing is possibly some if-combine?
Yes bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803
Richard Biener changed:
What|Removed |Added
Version|unknown |11.2.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102806
--- Comment #2 from Richard Biener ---
Yes, on the GIMPLE / Frontend level __builtin_shufflevector is implemented
mostly on the functional level and I don't remember doing any additional
specific optimizations (though it worked surprisingly well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102807
Bug ID: 102807
Summary: Simple code using ranges::views::keys does not compile
with clang
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
54 matches
Mail list logo
