https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82193
--- Comment #6 from Andrew Pinski ---
Just a quick note p1787
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html) moves
around the place where it says no diagnostic is required but the effect is the
same.
it is now in [class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #14 from Jerry DeLisle ---
This is interesting. Simply doing the following eliminates the ice.
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 0fb19cc9f0f..a9e538cc2a1 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108587
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #2 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82193
Andrew Pinski changed:
What|Removed |Added
CC||mserdarsanli at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108587
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108587
Bug ID: 108587
Summary: `decltype(x) x;` in struct declaration causes "changes
meaning of" error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #15 from Jan Hubicka ---
We get 47s runtime with -O2 -flto and 53s with -O2
-fno-inline-functions-called-once.
The call sequence is:
[local count: 109362591]:
_1656 = (unsigned long) _45;
_1655 = _1656 + ivtmp.1182_2540;
_2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108511
--- Comment #6 from Jan Hubicka ---
The function is used to discard early summaries that will lead to external
calls. This saves some memory allocations.
At this stage we have identified prevailing symbols and they are first in the
next_sharing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108565
--- Comment #5 from Jan Hubicka ---
Teaching modref that THIS parameter of all destructors is nonescape looks like
interesting idea (and easy to implement).
Memory stores are currently indeed handled as "anyting may happen". modref does
dataflo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108585
--- Comment #5 from Andrew Pinski ---
"" will start to use the rep at 64*8 ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #39 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
>
> --- Comment #35 from Vladimir Makarov ---
> (In reply to Jakub Jelinek from comment #34)
> > Seems right now DECL_NONALIASED is only used on these c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108585
Andrew Pinski changed:
What|Removed |Added
Summary|Using std::byte instead of |memset uses SSE stores but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108585
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108585
--- Comment #2 from Andrew Pinski ---
*** Bug 108586 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108586
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108585
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108586
Bug ID: 108586
Summary: Using std::array instead of a plain array results in
different (worse?) code in array zero initialization
Product: gcc
Version: unknown
Status: U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108585
Bug ID: 108585
Summary: Using std::byte instead of char results in different
(worse?) code in array zero initialization
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108582
--- Comment #6 from Andrew Pinski ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610817.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108529
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:a8ef7eec0c323a8752ad5babde6e4add4f224898
commit r12-9080-ga8ef7eec0c323a8752ad5babde6e4add4f224898
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106209
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:6dc4f984dd14ffad34e0540f2030f553579adefd
commit r12-9079-g6dc4f984dd14ffad34e0540f2030f553579adefd
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:523ee9f5994961b27c61d46b27dbe064f68d0d76
commit r12-9077-g523ee9f5994961b27c61d46b27dbe064f68d0d76
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108421
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:0e4c239ebde0a926832e3bcaae707eabf81927ff
commit r12-9078-g0e4c239ebde0a926832e3bcaae707eabf81927ff
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108501
--- Comment #7 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:daa4c49a4773f274b7a784cedd7b0e0b3c59523b
commit r12-9076-gdaa4c49a4773f274b7a784cedd7b0e0b3c59523b
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108502
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:4c6475148ac5d53449948665d7d94cfee5b549ac
commit r12-9075-g4c6475148ac5d53449948665d7d94cfee5b549ac
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108529
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108527
--- Comment #9 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:22afa4947584c701633a79fd8750c9ceeaa96711
commit r13-5479-g22afa4947584c701633a79fd8750c9ceeaa96711
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:aba9ff8f30d4245294ea2583de1dc28f1c7ccf7b
commit r13-5478-gaba9ff8f30d4245294ea2583de1dc28f1c7ccf7b
Author: Harald Anlauf
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108582
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|13.0
/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230128 (experimental) [master r12-4647-g3f861a5c8fd] (GCC)
[595] %
[595] % gcctk -O3 small.c; ./a.out
[5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107360
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108582
--- Comment #4 from Andrew Pinski ---
This should fix the issue:
apinski@xeond:~/src/upstream-gcc/gcc/gcc$ git diff tree-ssa-phiopt.cc
diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt.cc
index c3a889dc593..a7ab6ce4ad9 100644
--- a/gcc/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103770
--- Comment #7 from Martin Uecker ---
Regression tests:
https://gcc.gnu.org/g:ebf7dd754a95bf9680bc53331a6b70f0cf83c045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108582
--- Comment #3 from Andrew Pinski ---
PHI g_9 reduced for COND_EXPR in block 7 to g_8.
statement un-sinked:
k_22 = k_11 | iftmp.5_13;
Removing basic block 8
;; basic block 8, loop depth 0
;; pred: 7
# iftmp.5_13 = PHI <2(7)>
;; succ:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108582
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108582
Andrew Pinski changed:
What|Removed |Added
Version|unknown |13.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:6464409b0c7077e36858989b5dae302e2d26f45a
commit r13-5475-g6464409b0c7077e36858989b5dae302e2d26f45a
Author: Jonathan Yong <10wa...@g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108150
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:ff3d99c5e72126cf8d4c7611a63a82dfc476cdbe
commit r13-5474-gff3d99c5e72126cf8d4c7611a63a82dfc476cdbe
Author: Jonathan Yong <10wa...@g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
--- Comment #8 from postmaster at raasu dot org ---
I know enough C that you can't write code like:
int i = 0x;
This is not equal to:
int i = -1;
or
int i = (-1);
---
Largest literal you can assign to "int" is "0x7FFF". Any lar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #38 from Tang, Feng ---
Created attachment 54368
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54368&action=edit
objdump of prep_compound_page() with patch in comment 35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #37 from Tang, Feng ---
Created attachment 54367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54367&action=edit
page_alloc.i with patch in comment 35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #36 from Tang, Feng ---
(In reply to Vladimir Makarov from comment #35)
> (In reply to Jakub Jelinek from comment #34)
> > Seems right now DECL_NONALIASED is only used on these coverage vars and on
> > Fortran caf tokens, so perhaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
Bug ID: 108583
Summary: [13 Regression] wrong code with vector division by
uint16 at -O2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
ported LTO compression algorithms: zlib
gcc version 13.0.1 20230128 (experimental) [master r12-4647-g3f861a5c8fd] (GCC)
[618] %
[618] % gcctk -O3 small.c; ./a.out
[619] %
[619] % gcctk -O3 -fno-tree-ccp -fno-tree-dce small.c
during GIMPLE pass: phiopt
small.c: In function ‘main’:
small.c:3:5: interna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
--- Comment #7 from Andrew Pinski ---
Wrong again.
In c, 1 is int, if you want unsigned int type use 1u.
This forum is not to learn C and it is obvious you don't know the basics of the
language.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
--- Comment #6 from postmaster at raasu dot org ---
There is wrong assumption again... Literal "1" is always unsigned as there is
no implicit signed literals, even though there is explicit signed literals...
When somebody writes "-1" it is treate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108581
--- Comment #1 from saitofuyuki at jamstec dot go.jp ---
Created attachment 54365
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54365&action=edit
compiler output
command to compile:
% gfortran -O0 -Wall -v -save-temps dtest.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108581
Bug ID: 108581
Summary: wrong assignment on two-rank array with
deferred-length characters
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
--- Comment #5 from Andrew Pinski ---
You are still confused as the assembly code is correct.
Let's start over here.
Take:
char* a = (char*)malloc(1 << bits);
1 << bits is done in int type as the literal 1 has the type of int (because
that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
--- Comment #4 from postmaster at raasu dot org ---
I'm not mixing things... The assembly code clearly says it's using 32-bit
shift. Both with 32-bit and 64-bit architectures by default left-hand side of
shift operation is 32 bits (EAX instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
--- Comment #3 from Andrew Pinski ---
(In reply to postmaster from comment #2)
> If I try to shift to highest bit of signed type, the compiler will reject
> the code and that is correct behaviour. The point here is that left-hand
> side of the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
--- Comment #2 from postmaster at raasu dot org ---
If I try to shift to highest bit of signed type, the compiler will reject the
code and that is correct behaviour. The point here is that left-hand side of
the shift operation is by default same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108579
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection,
|
56 matches
Mail list logo
