On 12/10/2021 3:04 AM, Martin Liška wrote:
It happens that options are parsed and various diagnostics happen
in finish_options. That's a proper place as the function is also called
for optimize/target attributes (pragmas). However, it is possible that
target overwrites an option from command l
On 12/8/2021 9:49 AM, Martin Sebor via Gcc-patches wrote:
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls to atomic functions with invalid
memory orders are diagnosed even though the C atomic functions
are defined as macros in the system header.
On 12/17/2021 2:42 PM, Siddhesh Poyarekar wrote:
Since all computations in tree-object-size are now done in sizetype and
not HOST_WIDE_INT, comparisons after conversion to HOST_WIDE_INT would
be incorrect. Instead, truncate unknown (object_size_type) to sizetype
to compare with the computed s
Restore i686 bootstrap by requiring TARGET_64BIT for any_mul_highpart
peephole.
PR bootstrap/103785
* config/i386/i386.md: Require TARGET_64BIT for any_mul_highpart
peephole.
---
gcc/config/i386/i386.md | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/
* gcc.target/i386/smuldi3_highpart.c: Replace long with long long.
---
gcc/testsuite/gcc.target/i386/smuldi3_highpart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/smuldi3_highpart.c
b/gcc/testsuite/gcc.target/i386/smuldi3_highpart.c
i
Sorry, sent an incomplete email. it was missing this part:
On Thu, Nov 25, 2021 at 03:12:32PM -0600, Segher Boessenkool wrote:
> > +;; int fegetround(void)
> > +;;
> > +;; This expansion for the C99 function only expands for compatible
> > +;; target libcs. Because it needs to return one of FE_DOW
Hi Segher,
On Thu, Nov 25, 2021 at 03:12:32PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 24, 2021 at 08:48:47PM -0300, Raoni Fassina Firmino wrote:
> > gcc/ChangeLog:
> > * builtins.c (expand_builtin_fegetround): New function.
> > (expand_builtin_feclear_feraise_except
On 12/22/2021 5:57 AM, Martin Liška wrote:
I replaced and verified http:// links for various domains.
Ready to be installed?
Tahnks,
Martin
gcc/ada/ChangeLog:
* doc/share/gnu_free_documentation_license.rst: Replace http://
with https.
* gnat-style.texi: Likewise.
* gnat_rm.tex
On Mon, Dec 20, 2021 at 2:22 PM H.J. Lu wrote:
>
> On Mon, Dec 20, 2021 at 12:38 PM Jakub Jelinek wrote:
> >
> > On Mon, Dec 20, 2021 at 11:44:08AM -0800, H.J. Lu wrote:
> > > The problem is in
> > >
> > > (define_memory_constraint "TARGET_MEM_CONSTRAINT"
> > > "Matches any valid memory."
> > >
On Tue, 21 Dec 2021 at 17:56, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> On 21/12/21 7:28 am, Daniel Krügler wrote:
> > Am Di., 21. Dez. 2021 um 07:08 Uhr schrieb François Dumont via
> > Libstdc++ :
> >> Hi
> >>
> >> Is there a chance for this patch to be integrated for
On 12/22/21 22:09, Azat Khuzhin via Gcc-patches wrote:
So what is the right way here?
- migrate all tests
- write test only for setbuffer()
- do not add any tests, since they are covered in llvm repo
Hello.
Yes, we don't automatically sync sanitizer tests when we merge from master.
Historicall
On Thu, Dec 23, 2021 at 10:35 AM Roger Sayle wrote:
>
> Hi Uros,
>
> A huge thanks for the list of suggested improvements to the -Oz related
> patches.
> I've combined them altogether in the submission below, which makes sense now
> that everything is implemented using peephole2. The implementat
Hi Uros,
A huge thanks for the list of suggested improvements to the -Oz related patches.
I've combined them altogether in the submission below, which makes sense now
that everything is implemented using peephole2. The implementation of
push/pop via peephole2 is exactly as you've suggested, also
From: LiaoShihua
because riscv32 not support __int128, so skip if int128 not support.
gcc/testsuite\ChangeLog:
* gcc.target/riscv/pr103302.c: skip if int128 not support
---
gcc/testsuite/gcc.target/riscv/pr103302.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
14 matches
Mail list logo