https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110007
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110013
--- Comment #2 from Devin Hussey ---
Scratch that. There is a somewhat easy way to fix this following psABI AND
using MMX with SSE.
Upon calling a function, we can have the following sequence
func:
movdq2q mm0, xmm0
movq mm1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110013
--- Comment #1 from Devin Hussey ---
As a side note, the official psABI does say that function call parameters use
MM0-MM2, if Clang follows its own rules then it means that the supposed
stability of the ABI is meaningless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110013
Bug ID: 110013
Summary: [i386] vector_size(8) on 32-bit ABI
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103325
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109512
--- Comment #2 from kargl at gcc dot gnu.org ---
This patch catches the need for an external attribute.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 6e42397c2ea..1e19712b413 100644
--- a/gcc/fortran/resolve.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110011
--- Comment #2 from Andrew Pinski ---
(In reply to Vincent Lefèvre from comment #0)
> (gdb) print m
> $1 = 5.96937875341074040910051755689516189e-4947
Note This corresponds to:
m2:
.long 0
.long 2146435072
.long 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109512
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110011
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|-mfull-toc
:: p
end type
end module
$ gfortran gfortran-20230527.f90 -c
f951: internal compiler error: in resolve_fl_derived, at
fortran/resolve.cc:15532
0x699d67 resolve_fl_derived
../../gcc/fortran/resolve.cc:15532
0x79c3df resolve_symbol
../../gcc/fortran/resolve.cc:15916
0x7c7c32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85234
Andrew Pinski changed:
What|Removed |Added
Summary|missed optimisation |missed optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110010
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110011
Bug ID: 110011
Summary: -mfull-toc yields incorrect _Float128 constants on
power9
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110010
Bug ID: 110010
Summary: (a>>N) != (b>>N) is not optimized to (a^b) >= (1<>N) != (b>>N);
}
```
This could be optimized down to just `return (a^b) <= (1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
Bug ID: 110009
Summary: Another missing ABS detection
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #6 from Nikolas Klauser ---
(In reply to Florian Weimer from comment #5)
> How hard is this to use in practice? With current Clang, this:
>
> “
> template
> class S {
> __attribute__ ((visibility ("hidden"),
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110007
--- Comment #5 from Richard Yao ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Richard Yao from comment #3)
> > (In reply to Andrew Pinski from comment #2)
> > > (In reply to Richard Yao from comment #0)
> > > > Having the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #29 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #25)
> Created attachment 55175 [details]
> Patch which fixes `signed < 0`
>
> This patch improves comment #20 .
I ran into a code generation regression with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110008
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110008
Bug ID: 110008
Summary: early returns from functions result in suboptimal code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110007
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Yao from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > (In reply to Richard Yao from comment #0)
> > > Having the ability to specify __builtin_unpredictable() as a hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110007
--- Comment #3 from Richard Yao ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Richard Yao from comment #0)
> > Having the ability to specify __builtin_unpredictable() as a hint to
> > encourage the compiler to use cmov would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110007
--- Comment #2 from Andrew Pinski ---
(In reply to Richard Yao from comment #0)
> Having the ability to specify __builtin_unpredictable() as a hint to
> encourage the compiler to use cmov would be useful for implementing
> algorithms like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110007
--- Comment #1 from Andrew Pinski ---
Note x86 backend still will reject if there are two cmovs close to another
because of some cores are much worse with 2 close to another another.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596
Andrew Pinski changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110005
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98801
Richard Yao changed:
What|Removed |Added
CC||richard.yao at alumni dot
stonybro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110007
Bug ID: 110007
Summary: Implement support for Clang’s
__builtin_unpredictable()
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110006
Bug ID: 110006
Summary: friend function template with NTTP and constraint
doesn't match existing declaration
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110005
Bug ID: 110005
Summary: Writable strings seem too greedy in overload
resolution
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110004
Bug ID: 110004
Summary: large increase in profile mismatches on tramp3d
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110003
Bug ID: 110003
Summary: Wrong source line listed for unused parameters
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711
--- Comment #12 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:ed6a9a35799c9298321d1589533767c2bb6f8d42
commit r14-1307-ged6a9a35799c9298321d1589533767c2bb6f8d42
Author: liuhongt
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110002
--- Comment #1 from Thorsten Otto ---
When using -fcpp, gm2cc1 invokes cc1 only from the configured $(libexec)
directory, eg. /usr/lib64/gcc/x86_64-suse-linux/13/cc1. But when installed in a
different directory, it should use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110002
Bug ID: 110002
Summary: Using -fcpp only invokes cc1 from pre-configured path
$(libexec)
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847
--- Comment #6 from Andrew Pinski ---
Just for reference here are the functions I tried to see which way was the best
(set_bool0 and set_bool0_ produce the best for x86):
void
set_bool(bool& fl, __UINT32_TYPE__ value)
{
bool t = fl;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847
--- Comment #5 from Andrew Pinski ---
Oh simple way to solve this to convert:
t2_7 = (unsigned int) t_4;
_1 = t1_6 | t2_7;
t_8 = _1 != 0;
Into:
t3_8 = t1_7 != 0;
_1 = t_5 | t3_8;
Which is smaller even.
(for bit_op (bit_ior bit_and
41 matches
Mail list logo
