ink -gsplit-dwarf has been
> changed quite recently not to imply -g.
My understanding was that that change hasn't gone in at this point, in
part because of the issue of changing the semantics of an existing
flag and discussions around whether -g implies debug info. Could you
confirm if this
7;t think this is correct, because (a <= b) traps and (a == b)
doesn't. The following helps:
--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -2144,7 +2144,7 @@ eliminate_redundant_comparison (enum tree_code
opcode,
if (TREE_CODE (curr->op) != SSA_NAME)
return fals
On Tue, Nov 24, 2020 at 5:19 PM Joseph Myers wrote:
>
> On Wed, 25 Nov 2020, (Cron Daemon) via Gccadmin wrote:
>
> > === Working on: master ===
> > branch pulled and checked out
> > 61 revisions since last Daily bump
> > Traceback (most recent call la
Hello, I am PRACHURYA PRAN SARMA from India, I am a first year Computer
science and engineering student and I want to contribute and work in the
lovely organisation. I know c language and I am learning c++ too. I am also
going to participate in GSoC 2021.
Thank you.
-g enables debuginfo generation
> > > and no additional -g is needed to keep things consistent.
> >
> > I think we lost that consistency already, I think -gsplit-dwarf has been
> > changed quite recently not to imply -g.
>
> My understanding was that that change hasn&
On Wed, Nov 25, 2020 at 8:15 AM Marc Glisse wrote:
>
> On Wed, 25 Nov 2020, Ilya Leoshkevich via Gcc wrote:
>
> > I have a C floating point comparison (a <= b && a >= b), which
> > test_for_singularity turns into (a <= b && a == b) and vectorizer tu
On Wed, 2020-11-25 at 10:53 +0100, Richard Biener wrote:
> On Wed, Nov 25, 2020 at 8:15 AM Marc Glisse
> wrote:
> > On Wed, 25 Nov 2020, Ilya Leoshkevich via Gcc wrote:
> >
> > > I have a C floating point comparison (a <= b && a >= b), which
> >
nt.
> > >
> > > I think we lost that consistency already, I think -gsplit-dwarf has been
> > > changed quite recently not to imply -g.
> >
> > My understanding was that that change hasn't gone in at this point, in
> > part because of the issue of changing
I have to make filename work correctly under none UTF-8 exec charset. Do not
tell me to use locale since locale is not thread-safe and configure locale is a
huge issue.
I do not use any C stdio or C++ iostream facilities since I create my own I/O
library from scratch. However, this is something
On 11/25/20 8:15 AM, Zack Weinberg wrote:
printf(“Hello World\n”); is UB under -fexec-charset= EBCDIC. WTF WTF!!!
It's not undefined behavior. It does, however, appear to trip various
bugs in GCC.
$ cat test.c
#include
int main(void) { printf("hello world\n"); }
$ gcc-9 -
Glibc cannot deal with EBCDIC or any other charset besides UTF-8 since GCC
itself does not emit exec-coding set to C library and C library just could not
deal with it.
Even glibc could deal with it, GCC allows different exec-charset to be linked
with each other which is definitely an undefined
Good day
Well, I had a look at your website and should say that it is really
impressive. I like the content you share as well as the style you use.
Today, I am writing to ask about advert opportunities on your website.
I’m greatly interested:
- Guest posts,
- Link insertion (in the existi
I've touched on the subject a few times, e.g.
https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
Libstdc++ code is indented by 2 columns for the enclosing namespace,
usually another two for being in a template, and is
在 2020/11/27 上午7:50, Jonathan Wakely via Gcc 写道:
> I've touched on the subject a few times, e.g.
> https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
> and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
>
> Libstdc++ code is indented by 2 columns for the
On Fri, Nov 27, 2020 at 3:48 AM Liu Hao via Gcc wrote:
>
> 在 2020/11/27 上午7:50, Jonathan Wakely via Gcc 写道:
> > I've touched on the subject a few times, e.g.
> > https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
> > and https://gcc.gnu.org/pipermail/
paren is on the
first line, I know instantly that I'm
looking at a function call. That sort of style probably fits better
the C++ code in libstdc++ than the code
in gcc, because in libstdc++ code we don't have a space before the
argument list.
在 2020/11/27 下午4:14, Richard Biener 写道:
>
> I prefer the ( on the next line. The argument list can be two spaces
> indented from
> the function name or "right justified" (I think the latter looks
> visually better).
>
The right justification thing looks reasonable. For example, I think this
``
a general question/thought/rumination here, though.
Shouldn't the paren-style and the line length
of libstdc++ be mainly decided by those who develop and maintain it?
It's already not written in the same style
as gcc is, so tweaking that different style to better suit the need of
a template-h
* Joseph Myers:
> glibc effectively treats them as unspecified behavior - we don't expect
> them to produce any particular meaningful function return value (this
> includes the possibility that such an invalid encoding might be returned
> by a function given such an encoding as input), but if t
and email mentioning the idea of this not being the
final solution:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49103#c12
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-06/msg00480.html
Email mentioning the idea to remove it later
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-06/msg01025.html
at least make the classification
> consistent with gcc.
Yes, I agree.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
Am 27.11.20 um 00:50 schrieb Jonathan Wakely via Gcc:
Does anybody object to raising the line length for libstdc++ code
(not the rest of GCC) to 100 columns?
In gfortran, we have a habit of using long and expressive function
names (which is good) which lead to lots of columns of indentation
I am pleased to announce that the GCC Steering Committee has
appointed Claudiu Zissulescu as ARC Co-Maintainer.
Please join me in congratulating Claudiu on his new role.
Claudiu, please update your listing in the MAINTAINERS file.
Happy hacking!
David
On 11/27/20 5:47 AM, Matthew Malcomson via Gcc wrote:
> Hi there,
>
> I was just looking through the history of how some code came about,
> and get the impression that DECL_NONSHAREABLE was meant to be removed.
>
> It seems like it was added to solve PR49103, with the idea
Hello!
I am trying to understand something unexpected I am seeing in the relocations
placed into a compiled Linux kernel for the .debug_info section. Those
relocations seem to change the names of various entries in the debug info:
[65] .debug_info PROGBITS
o if user explicitly specifies debug level.
The gcc documentation says
"If you use multiple -g options, with or without level numbers, the last such
option is the one that is effective."
With complex, like buck, build systems with various config files, and hard
coded overrides that'
On 11/24/20 6:16 AM, Thomas Schwinge wrote:
> Hi!
>
> Ping. Anybody got an opinion on the approach we should take?
Could we set warning_threshold to a value to inhibit this behavior
completely. It seems backwards to me that warnings have this effect.
Jeff
bering the spelling) to
Clang to support this use case of "If we're generating DWARF, make it
DWARFv5")
> This also helps to avoid the scenario if user explicitly specifies debug
> level. The gcc documentation says
> "If you use multiple -g options, with or without level
d":
Relocation section '.rela.debug_info' at offset 0xc4b2498 contains 12956143
entries:
0d85 002a000a R_X86_64_32 .debug_str +
66d60
Any other thoughts?
Sincerely,
Bill Messmer
-Original Message-
From: Mark Wielaard
Sent:
From: David Blaikie
Sent: Monday, November 30, 2020 12:09 PM
To: Alexander Yermolovich
Cc: Richard Biener ; Jakub Jelinek
; Mark Wielaard ; gcc@gcc.gnu.org
; ikud...@accesssoftek.com ;
mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On
Hi,
For the test mentioned in PR, I was trying to see if we could do
specialized expansion for vcond in target when operands are -1 and 0.
arm_expand_vcond gets the following operands:
(reg:V8QI 113 [ _2 ])
(reg:V8QI 117)
(reg:V8QI 118)
(lt (reg/v:V8QI 115 [ a ])
(reg/v:V8QI 116 [ b ]))
(reg/v:
alter).
Sincerely,
Bill Messmer
-Original Message-
From: Mark Wielaard
Sent: Monday, November 30, 2020 6:39 PM
To: Bill Messmer
Cc: gcc@gcc.gnu.org
Subject: Re: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP
references)
Hi Bill,
On Mon, Nov 30, 2020 at 10:22:34PM +,
On Mon, Nov 30, 2020 at 6:41 PM Mark Wielaard wrote:
>
> Hi Bill,
>
> On Mon, Nov 30, 2020 at 10:22:34PM +, Bill Messmer wrote:
>
> > I'm still a bit confused here. And the reason I ask this is because
> > I open this particular vmlinux image with an OSS ELF/DWARF
> > library... which gives
On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich
wrote:
>
>
> --
> *From:* David Blaikie
> *Sent:* Monday, November 30, 2020 12:09 PM
> *To:* Alexander Yermolovich
> *Cc:* Richard Biener ; Jakub Jelinek <
> ja...@redhat.com>; M
Thank you for your support,
Claudiu
From: David Edelsohn
Sent: Sunday, November 29, 2020 9:47 PM
To: Claudiu Zissulescu ; gcc@gcc.gnu.org
Subject: Claudiu Zissulescu appointed ARC Co-Maintainer
I am pleased to announce that the GCC Steering Committee has
From: David Blaikie
Sent: Tuesday, December 1, 2020 10:33 AM
To: Alexander Yermolovich
Cc: Richard Biener ; Jakub Jelinek
; Mark Wielaard ; gcc@gcc.gnu.org
; ikud...@accesssoftek.com ;
mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On
On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich
wrote:
>
>
> --
> *From:* David Blaikie
> *Sent:* Tuesday, December 1, 2020 10:33 AM
> *To:* Alexander Yermolovich
> *Cc:* Richard Biener ; Jakub Jelinek <
> ja...@redhat.com>; M
From: David Blaikie
Sent: Wednesday, December 2, 2020 1:12 PM
To: Alexander Yermolovich
Cc: Richard Biener ; Jakub Jelinek
; Mark Wielaard ; gcc@gcc.gnu.org
; ikud...@accesssoftek.com ;
mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On
On Tue, 1 Dec 2020 at 16:39, Richard Biener wrote:
>
> On Tue, 1 Dec 2020, Prathamesh Kulkarni wrote:
>
> > Hi,
> > For the test mentioned in PR, I was trying to see if we could do
> > specialized expansion for vcond in target when operands are -1 and 0.
> > arm_expand_vcond gets the following ope
On 29/11/2020 17:38, Florian Weimer wrote:
> * Allan Sandfeld Jensen:
>
>> If you _do_ change it. I would suggest changing it to 120, which is next
>> common step for a lot of C++ projects.
>
> 120 can be problematic for a full HD screen in portrait mode. Nine
> pixels per character is not a lo
On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich
wrote:
>
>
> --
> *From:* David Blaikie
> *Sent:* Wednesday, December 2, 2020 1:12 PM
> *To:* Alexander Yermolovich
> *Cc:* Richard Biener ; Jakub Jelinek <
> ja...@redhat.com>; M
To:* Alexander Yermolovich
>> *Cc:* Richard Biener ; Jakub Jelinek <
>> ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org <
>> gcc@gcc.gnu.org>; ikud...@accesssoftek.com ;
>> mask...@google.com
>> *Subject:* Re: DWARF64 gcc/clan
On Thu, 3 Dec 2020 at 16:35, Richard Biener wrote:
>
> On Thu, 3 Dec 2020, Prathamesh Kulkarni wrote:
>
> > On Tue, 1 Dec 2020 at 16:39, Richard Biener wrote:
> > >
> > > On Tue, 1 Dec 2020, Prathamesh Kulkarni wrote:
> > >
> > > > Hi,
> > > > For the test mentioned in PR, I was trying to see if
From: Richard Biener
Sent: Friday, December 4, 2020 12:36 AM
To: David Blaikie
Cc: Alexander Yermolovich ; Jakub Jelinek ;
Mark Wielaard ; gcc@gcc.gnu.org ;
ikud...@accesssoftek.com ; mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On Thu
I'm looking for a way to get the FUNCTION_DECL for the library
(i.e., non-built-in) form of a function given the corresponding
built-in DECL. Is there an API I can all with either the built
-in DECL or its code to get it in the middle end?
In C, what I'm looking for appears to be DECL_CHAIN(decl
On 12/4/20 4:33 PM, Martin Sebor wrote:
I'm looking for a way to get the FUNCTION_DECL for the library
(i.e., non-built-in) form of a function given the corresponding
built-in DECL. Is there an API I can all with either the built
-in DECL or its code to get it in the middle end?
In C, what I'm
gcc does not reduce to call result if called function is not static in
-O2 (will do with -O2)
clang and msvc does it also in -O2 regardless of the function beeing
static or not
can someone explain to me why the -O2 optimizer is not able(allowed) to
reduce this small sample the same way as clang
Am 05.12.2020 um 13:04 schrieb Jan Hubicka:
> gcc does not reduce to call result if called function is not static in
> -O2 (will do with -O2)
> clang and msvc does it also in -O2 regardless of the function beeing
> static or not
>
> can someone explain to me why the -O2 opt
Am 05.12.2020 um 14:25 schrieb Eric Botcazou:
> can someone explain to me why the -O2 optimizer is not able(allowed) to
> reduce this small sample the same way as clang/msvc?
Change the name of the function to something else than "main".
that works, thanks!
Hi,
it seems that git commits are no longer automatically transferred
to the relevant PRs.
Recent example: I don't see
https://gcc.gnu.org/pipermail/gcc-cvs/2020-December/338684.html
in PR98156, although the ChangeLog was
Upper cobound is determined by num_images(), not this_
On Fri, 4 Dec 2020 at 17:18, Richard Biener wrote:
>
> On Fri, 4 Dec 2020, Prathamesh Kulkarni wrote:
>
> > On Thu, 3 Dec 2020 at 16:35, Richard Biener wrote:
> > >
> > > On Thu, 3 Dec 2020, Prathamesh Kulkarni wrote:
> > >
> > > > On Tue, 1 Dec 2020 at 16:39, Richard Biener wrote:
> > > > >
> >
On Fri, Dec 4, 2020 at 7:01 PM Alexander Yermolovich
wrote:
>
>
> --
> *From:* Richard Biener
> *Sent:* Friday, December 4, 2020 12:36 AM
> *To:* David Blaikie
> *Cc:* Alexander Yermolovich ; Jakub Jelinek <
> ja...@redhat.com>; M
On Sat, Dec 5, 2020 at 1:55 AM Martin Sebor via Gcc wrote:
>
> On 12/4/20 4:33 PM, Martin Sebor wrote:
> > I'm looking for a way to get the FUNCTION_DECL for the library
> > (i.e., non-built-in) form of a function given the corresponding
> > built-in DECL. Is there
On Mon, 7 Dec 2020 at 13:01, Richard Biener wrote:
>
> On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
>
> > On Fri, 4 Dec 2020 at 17:18, Richard Biener wrote:
> > >
> > > On Fri, 4 Dec 2020, Prathamesh Kulkarni wrote:
> > >
> > > > On Thu, 3 Dec 2020 at 16:35, Richard Biener wrote:
> > > > >
> >
On Mon, Dec 7, 2020 at 5:47 PM Richard Biener wrote:
>
> On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
>
> > On Mon, 7 Dec 2020 at 13:01, Richard Biener wrote:
> > >
> > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> > >
> > > > On Fri, 4 Dec 2020 at 17:18, Richard Biener wrote:
> > > > >
>
On Mon, 7 Dec 2020 at 16:15, Hongtao Liu wrote:
>
> On Mon, Dec 7, 2020 at 5:47 PM Richard Biener wrote:
> >
> > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> >
> > > On Mon, 7 Dec 2020 at 13:01, Richard Biener wrote:
> > > >
> > > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> > > >
> >
On Mon, Dec 07, 2020 at 08:14:20AM +0100, Richard Biener via Gcc wrote:
> > Sorry, just going around in circles a bit, I guess this may be a better
> > summary:
> > If I had to pick a -g flag/semantic for this, I guess I'd pick
> > -gdwarf32/64 without implied -g
On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
wrote:
>
> On Mon, 7 Dec 2020 at 16:15, Hongtao Liu wrote:
> >
> > On Mon, Dec 7, 2020 at 5:47 PM Richard Biener wrote:
> > >
> > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> > >
> > > > On Mon, 7 Dec 2020 at 13:01, Richard Biener wrote:
The current libstdc++ basic_file_stdio.cc code assumes a POSIX API
underneath the stdio implementation provided by the host libc. This
means that the host must provide a fairly broad POSIX file API,
including read, write, open, close, lseek and ioctl.
This patch changes basic_file_stdio.cc to only
These are the changes to autoconf files for the pure-stdio patch
Signed-off-by: Keith Packard
---
libstdc++-v3/config.h.in | 3 +++
libstdc++-v3/configure | 23 +++
2 files changed, 26 insertions(+)
diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
index 72
This option directs the library to only use simple stdio APIs instead
of using fileno to get the file descriptor for use with POSIX APIs.
Signed-off-by: Keith Packard
---
libstdc++-v3/ChangeLog | 13 ++
libstdc++-v3/acinclude.m4 | 13 ++
libstdc++-v3/
Thanks for the context, all!
On Mon, Dec 7, 2020 at 3:22 AM Jakub Jelinek wrote:
> On Mon, Dec 07, 2020 at 08:14:20AM +0100, Richard Biener via Gcc wrote:
> > > Sorry, just going around in circles a bit, I guess this may be a better
> > > summary:
> > > If I had
on mainline for the same reasons that
> the LLVM developers do, to ensure that everyone is working in the same
> branch in the upstream tree. And it is easiest to do that if that branch
> is mainline.
>
> This is just a binutils and gcc proposal at the moment, but we might need
> s
On Mon, 7 Dec 2020 at 17:37, Hongtao Liu wrote:
>
> On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 7 Dec 2020 at 16:15, Hongtao Liu wrote:
> > >
> > > On Mon, Dec 7, 2020 at 5:47 PM Richard Biener wrote:
> > > >
> > > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
omputing would like to continue supporting MIPS
> > > architecture in GCC, although there are very few patches for MIPS
> > > recently. Any feedback is welcome.
>
> > Well, it's up to the GCC steering committee really to appoint maintainers
> > <https://gcc.gnu.or
to
checking errors or segfaults.
More specifically,
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index f1c8f0ee17f..11043406840 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -96,7 +96,7 @@ gfc_create_var_np (tree type, const char *prefix)
tree t;
t
Hi Tobias,
On 08.12.20 19:34, Thomas Koenig via Fortran wrote:
I would like to know the name of a variable created with
create_tmp_var_raw, but it is not clear to my how to do it.
...
t = create_tmp_var_raw (type, prefix);
-
+ dprintf (2, "%s\n", IDENTIFIER_POINTER (DECL_NAME (t)));
I t
everyone is working in the same
> branch in the upstream tree. And it is easiest to do that if that branch
> is mainline.
>
> This is just a binutils and gcc proposal at the moment, but we might need
> something on the gdb side later, like a
> set riscv experimental-extensions 1
On Wed, 9 Dec 2020 at 09:28, webmaster wrote:
>
> Hello,I'm wondering why GCC does not throw any warning when a module global
> variable is set (write) but never used (read).Is this behavior wanted? Does
> it makes sense to add such warning?Greets
This question seems to be mor
On Wed, Dec 09, 2020 at 10:50:22AM +0100, David Brown wrote:
> I'd say that it makes sense to have such a warning as a natural
> enhancement to the existing "-Wunused-but-set-variable" warning. But I
That is not really possible.
The -Wunused-but-set-* warning works by having two bits for the DECL
On Tue, 8 Dec 2020 at 14:36, Prathamesh Kulkarni
wrote:
>
> On Mon, 7 Dec 2020 at 17:37, Hongtao Liu wrote:
> >
> > On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 7 Dec 2020 at 16:15, Hongtao Liu wrote:
> > > >
> > > > On Mon, Dec 7, 2020 at 5:47 PM Richard Bi
On Wed, 9 Dec 2020 at 12:45, Tomar, Sourabh Singh via Gcc
wrote:
>
> Hi Folks,
>
> I observed some leaks using valgrind while compiling a sample program using
> GCC.
This seems more appropriate for gcc-h...@gcc.gnu.org instead.
> Could anyone aware of these details provi
On Wed, 9 Dec 2020 at 12:53, Jonathan Wakely wrote:
>
> On Wed, 9 Dec 2020 at 12:45, Tomar, Sourabh Singh via Gcc
> wrote:
> >
> > Hi Folks,
> >
> > I observed some leaks using valgrind while compiling a sample program using
> > GCC.
>
> This se
On Wed, Dec 09, 2020 at 12:55:40PM +, Jonathan Wakely via Gcc wrote:
> > > I observed some leaks using valgrind while compiling a sample program
> > > using GCC.
> >
> > This seems more appropriate for gcc-h...@gcc.gnu.org instead.
> >
> > > Co
Hi,
I have observed that STV2 pass added ~20% on CPU2006 456.hmmer with mostly
by transforming V4SI operations. Looking at the pass itself, it looks like
it might be transformed into RTL architecture-independent, and the pass
deals only not wide integer operations. I think it might be useful on oth
It seems better with your PR97872 fix on i386.
Cat test.c
typedef char v16qi __attribute__ ((vector_size(16)));
v16qi f1(v16qi a, v16qi b) {
return (a & b) != 0;
}
before
f1(char __vector(16), char __vector(16)):
pand %xmm1, %xmm0
pxor %xmm1, %xmm1
pcmpeqb %xmm1, %xmm0
pcmpeqd %xmm1, %xmm1
pand
BuBleik SAL
Virtual Office & Virtual Assistant
Working from home and you don't want to miss a call. We got you covered.
The Voicemail To Email subscription with BuBleik SAL, offers you the luxury to
have a city land line telephone number, answered by an automated welcome
message of your c
Hi,
I have a maybe silly question about whether there is any *standard*
or *options* (like -ffast-math) for GCC that allow double to float
demotion optimization? For example,
1) from PR22326:
#include
float foo(float f, float x, float y) {
return (fabs(f)*x+y);
}
The fabs will return
On Thu, Dec 10, 2020 at 9:47 AM Xionghu Luo via Gcc wrote:
>
> Hi,
>
> I have a maybe silly question about whether there is any *standard*
> or *options* (like -ffast-math) for GCC that allow double to float
> demotion optimization? For example,
The only option we have to th
On Thu, 10 Dec 2020 at 17:11, Richard Biener wrote:
>
> On Wed, 9 Dec 2020, Prathamesh Kulkarni wrote:
>
> > On Tue, 8 Dec 2020 at 14:36, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 7 Dec 2020 at 17:37, Hongtao Liu wrote:
> > > >
> > > > On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
de to use float computations because we cannot really say
> whether it's safe (we do at the moment not implement value-range
> propagation for floating point types).
>
foo (double x, float y, float z)
{
return ( fabs (x) * y - z ) ;
}
int main ()
{
float res =
On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
> Hello,
> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
> __divdi3 is always output, even though it seems the use of the idiv
> instruction could be faster.
> This seems to remain even under -
ng point types).
> >
>
>foo (double x, float y, float z)
> {
> return ( fabs (x) * y - z ) ;
> }
>
> int main ()
> {
> float res = foo (1e38, 5.0, 3e38);
> printf ("res:%f\n", res);
> }
>
> (1) $ gcc a.c -Ofast -ffp-c
+cc.
On 2020/12/11 14:25, Xionghu Luo via Gcc wrote:
Thanks,
On 2020/12/10 17:12, Richard Biener wrote:
2) From PR90070:
double temp1 = (double)r->red;
double temp2 = (double)aggregate.red;
double temp3 = temp2 + (temp1 * 5.0);
temp1 * 5 could be not representable in float
On 11/12/2020 07:12, Marc Glisse wrote:
> On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
>
>> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
>> __divdi3 is always output, even though it seems the use of the idiv
>> instruction could be
On 2020/12/11 15:47, Richard Biener wrote:
>> Note that the add/sub sequence is different for (3) and (4) since
>> -funsafe-math-optimizations is implicitly true. "fp-contract=fast" in
>> (1) and (2) could avoid Inf as fmads could handle float overflow (verified
>> it on Power, not sure other ta
On 2020/12/11 15:47, Richard Biener wrote:
>> Note that the add/sub sequence is different for (3) and (4) since
>> -funsafe-math-optimizations is implicitly true. "fp-contract=fast" in
>> (1) and (2) could avoid Inf as fmads could handle float overflow (verified
>> it on Power, not sure other t
On Fri, Dec 11, 2020 at 10:44 AM Xionghu Luo wrote:
>
>
> On 2020/12/11 15:47, Richard Biener wrote:
> >> Note that the add/sub sequence is different for (3) and (4) since
> >> -funsafe-math-optimizations is implicitly true. "fp-contract=fast" in
> >> (1) and (2) could avoid Inf as fmads could ha
On Fri, 11 Dec 2020, Andrew Haley via Gcc wrote:
> On 11/12/2020 07:12, Marc Glisse wrote:
> > On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
> >
> >> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
> >> __divdi3 is always output
On Fri, Dec 11, 2020 at 07:04:28PM +0100, Martin Liška wrote:
> On 12/11/20 2:17 PM, Rainer Orth wrote:
> > Rainer Orth writes:
> >
> > > I noticed that gcc/DATESTAMP isn't updated any longer after this
> > > Friday. I doubt this is intentional...
&g
aster was bumped, but
> not any of the release branches:
>
> commit c5853240cdae1e727a65d1300e05307e5197bc69 (origin/releases/gcc-10)
> Author: GCC Administrator
> Date: Sun Dec 13 00:16:57 2020 +
>
> Daily bump.
>
> Can you please Jakub redirect output of t
On Mon, Dec 14, 2020 at 10:21:15AM +0100, Martin Liška wrote:
> On 12/14/20 10:05 AM, Jakub Jelinek wrote:
> > Note, last night r11 DATESTAMP bump actually succeeded, it was the other
> > branches that failed.
>
> I know.
>
> So please try to output the script output to a log. So that we can anal
On Mon, Dec 14, 2020 at 11:02:44AM +0100, Andreas Schwab wrote:
> On Dez 14 2020, Martin Liška wrote:
>
> > On 12/11/20 7:26 PM, Jakub Jelinek wrote:
> >> When running it manually it just completed without problems.
> >> So, no idea what happened.
> >
> > Morning.
> >
> > Unfortunately, today we h
On 12/14/20 9:02 AM, Martin Liška wrote:
> Hello.
>
> GCOV tests suffer from tests that would cover the intermediate format.
> It's a JSON format and and I'm attaching an example of its output.
>
> I would really like to use Python to make more complex tests:
>
> $ cat test_json.py
> import pyte
On 12/11/20 11:14 AM, Alejandro Colomar (man-pages) via Gcc wrote:
It looks like GCC recently moved from 'char *' to 'void *'.
This SO question[1] (4 years ago) quotes the GCC docs
and they had 'char *'.
__builtin___clear_cache in GCC has always been declared to
On Tue, Dec 15, 2020 at 05:02:24PM +0100, Thomas Schwinge wrote:
> Per the 'fold_convert_loc' code (cited below), we see that for 'type' of
> 'case INTEGER_TYPE' etc. -- which 'type' of 'case REFERENCE_TYPE' does
> "fall through" into -- we do not handle 'arg' of 'REAL_CST' like we do
> for 'type'
On 12/15/20 10:27 AM, Segher Boessenkool wrote:
> Hi!
>
> I have updated my CC0 removal branch I started in 2019:
> refs/users/segher/heads/cc0
> (yes I know this needs some patch series work; this branch rebases).
>
> I have tested it all on powerpc*, and sill test it with cross-compilers
> t
Gcc (trunk) appears to have added support for P0929
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0929r2.html>,
but the C++20 support page
<https://gcc.gnu.org/projects/cxx-status.html#cxx20> doesn't acknowledge
it. Oversight?
https://www.godbolt.org/z/a4EjaG
Tom.
On 12/16/20 4:22 PM, Tom Honermann via Gcc wrote:
Gcc (trunk) appears to have added support for P0929
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0929r2.html>,
but the C++20 support page
<https://gcc.gnu.org/projects/cxx-status.html#cxx20> doesn't
acknowled
Thanks for the correction!
Then the prototypes that changes from 'char *' to 'void *' in r269082
were not exposed to the user, right?
I guess then those are just internal implementation where GCC did use
'char *'.
__builtin___clear_cache was added to GCC in r126535
2701 - 2800 of 10345 matches
Mail list logo
