Ds Được gửi từ iPhone của tôi là sư phụ phụ huynh tg
On 24.05.2023 11:01, Hongtao Liu wrote:
> On Wed, May 24, 2023 at 3:58 PM Jan Beulich via Gcc wrote:
>>
>> Hello,
>>
>> for a couple of years I was meaning to extend the use of these AVX512F
>> insns beyond the pretty minimalistic ones there are so far. Now that I've
>> got around to at least draf
On Wed, May 24, 2023 at 3:58 PM Jan Beulich via Gcc wrote:
>
> Hello,
>
> for a couple of years I was meaning to extend the use of these AVX512F
> insns beyond the pretty minimalistic ones there are so far. Now that I've
> got around to at least draft something, I ran into a couple of issues I
> c
Hello,
for a couple of years I was meaning to extend the use of these AVX512F
insns beyond the pretty minimalistic ones there are so far. Now that I've
got around to at least draft something, I ran into a couple of issues I
cannot explain. I'd like to start with understanding the unexpected
effect
On Wed, Feb 01, 2023 at 12:29:02PM +0100, Florian Weimer via Gcc wrote:
> >> This impacts most (all?) Fortran code on GNU/Linux because libgfortran
> >> depends on libquadmath.
> >
> > Not anymore.
> > If GCC is configured against new enough glibc (with _Float128 support)
> > libgfortran.so.5 is no
* Jakub Jelinek:
> On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote:
>> I recently discovered that libquadmath registers custom printf callbacks
>> on load. As far as I can tell, this is done so that the Q format flag
>> can be used to print floating
On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote:
> I recently discovered that libquadmath registers custom printf callbacks
> on load. As far as I can tell, this is done so that the Q format flag
> can be used to print floating point numbers, using format strings
I recently discovered that libquadmath registers custom printf callbacks
on load. As far as I can tell, this is done so that the Q format flag
can be used to print floating point numbers, using format strings such
as "%Qf". To enable Q flag processing, libquadmath has to register
re
On 8 April 2016 at 11:09, Ulrich Windl wrote:
> Hello!
>
> Probably I'm doing something wrong, but I have some problems comparing a
> double with NAN: The value is NAN, but the test fails. Probably I should use
> isnana().
This mailing list is for discussing development of GCC, not help using
GC
On 08/04/16 11:09, Ulrich Windl wrote:
> Probably I'm doing something wrong, but I have some problems comparing a
> double with NAN: The value is NAN, but the test fails. Probably I should use
> isnana().
yes, that's how ieee works, nan != nan is true.
Hello!
Probably I'm doing something wrong, but I have some problems comparing a double
with NAN: The value is NAN, but the test fails. Probably I should use isnana().
Here's my test case:
---
#include
#include
int main()
{
double d = NAN;
assert(d == NAN);
return 0
29.03.2015 23:18, Godmar Back writes:
> Thanks. I'm a bit confused then what constitutes defined & undefined behavior.
>
> The actual situation I encountered is best described by this example:
>
> --
> /* Tested with gcc 4.4.7 and 4.8.2 -m32 */
> #include
> #include
>
> bool boolFunctionThatRe
On 29 March 2015 at 19:32, Godmar Back wrote:
> Why does assigning boolFunctionThatReturnsFalse to a variable f after
> the cast, instead of directly dereferencing it, silence the compiler's
> warnings?
Because the cast itself is OK, and the call that results in undefined
behaviour is separate fro
On Sun, Mar 29, 2015 at 3:26 PM, Andreas Schwab wrote:
> Godmar Back writes:
>
>> ps: I would like to see the warning, of course, since casting a bool
>> returning function to an int returning function is undefined behavior.
>
> The cast itself is ok, the undefined behavior only occurs when calli
Godmar Back writes:
> ps: I would like to see the warning, of course, since casting a bool
> returning function to an int returning function is undefined behavior.
The cast itself is ok, the undefined behavior only occurs when calling
it without casting back.
Andreas.
--
Andreas Schwab, sch..
Hi,
why does gcc (4.4.7 and 4.8.2) sometimes warn and sometimes not warn
when undefined behavior is invoked when making illegal function
pointer conversions?
For instance, consider the code below:
-
/* Tested with gcc 4.4.7 and 4.8.2 */
#include
#include
bool boolFunctionThatReturnsFa
Mark Mitchell wrote:
> As before, feel free to put questions that you would like to ask on this
> Wiki page:
I failed to include the URL.
It is:
http://gcc.gnu.org/wiki/Release%20Manager%20Q%26A
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Joseph Myers, Richard Guenther, and I will be hosting the second GCC
Release Manager Q&A on Thursday, August 5th at 9:00 AM Pacific Daylight
Time. (Jakub Jelinek is unfortunately unable to attend.)
As before, feel free to put questions that you would like to ask on this
Wiki page:
if you
On Thu, 27 May 2010, Mark Mitchell wrote:
> Thanks to all who participated in the GCC Release Manager Q&A on IRC
> earlier today. Joseph Myers logged the chat session and will put it on
> the GCC Wiki soon. There were a lot of good comments and questions.
http://gcc.gnu.org
Thanks to all who participated in the GCC Release Manager Q&A on IRC
earlier today. Joseph Myers logged the chat session and will put it on
the GCC Wiki soon. There were a lot of good comments and questions.
Thanks especially to Richard Guenther and Joseph Myers who both
accommodate
In:
http://gcc.gnu.org/ml/gcc/2010-05/msg00347.html
I indicated that I, and the other GCC RMs as available, would
participate in an interactive IRC discussion on May 27th at 9:00 AM Pacific.
As nobody has volunteered to moderate the IRC session, we'll use the
general-purpose GCC developer IRC ch
Joseph S. Myers wrote:
> I note that many of the questions already added to that page could be seen
> as suggesting a greater role for the RMs than there is at present in
> setting directions for GCC development. RMs (in their RM capacity) do not
> set priorities or make plans for GCC developm
On Tue, 18 May 2010, Mark Mitchell wrote:
> http://gcc.gnu.org/wiki/Release%20Manager%20Q%26A
I note that many of the questions already added to that page could be seen
as suggesting a greater role for the RMs than there is at present in
setting directions for GCC development. RMs (in their
NightStrike wrote:
>> If anyone would like to volunteer to set up a channel and/or moderate
>> the chat itself, please let me know.
> Can you just do it in #gcc on oftc?
That's certainly the fallback possibility. Though, for those not
interested, it would interrupt whatever else is being disc
On Tue, May 18, 2010 at 11:36 PM, Mark Mitchell wrote:
> Several people have asked that there be a forum for asking questions of
> and providing feedback to the GCC RMs. Since this is of course a very
> widely distributed community, the best medium for this seems to be an
> IRC chat. To that end
Several people have asked that there be a forum for asking questions of
and providing feedback to the GCC RMs. Since this is of course a very
widely distributed community, the best medium for this seems to be an
IRC chat. To that end, I'll be hosting a 1-hour session on May 27th at
9:00 AM Pacifi
Hello All
On the MELT branch, I need sometimes that cc1 be run even if there is no
input files. This is an unusual mode, but sometimes needed (This
actually is needed to have MELT lisp files translated into C; for
reasons not explained here, this is a special mode of my ./cc1 which
does that;
Also, http://people.redhat.com/dj/all_l4.i and
./cc1 -fpreprocessed all_l4.i -quiet -dumpbase all_l4.c -mcpu=m32cm \
-auxbase-strip all_l4.o -g -O2 -O2 -Wall -Wstrict-prototypes \
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings \
-std=gnu99 -version -o all_l4.s -dap -fdu
> So it looks like we have D.3720 + (unsigned int) &sstride which
> looks funny in of it self. Can you provide the tree dump before
> iv-opts and the one of iv-opts? It might explain what is going
> wrong?
http://people.redhat.com/dj/all_l4.c.105t.cunroll
http://people.redhat.com/dj/all_l4.c.10
On 9/25/07, DJ Delorie <[EMAIL PROTECTED]> wrote:
> I like that! Not quite enough info for some needs (like it's missing
> the machine mode and rtl assignments, which I often need), but much
> cleaner:
>
> MEM[base: D.3720 + (unsigned int) &sstride] = MEM[base: D.3718, offset: 10]
Usually I use d
> From what I recall and what I remember the main issue is that IV-opts
> like producing:
> [MEM index: ]
> Note it might be better to use debug_generic_expr instead of
> debug_tree (it is easier to read in most cases).
I like that! Not quite enough info for some needs (like it's missing
the ma
On 9/24/07, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> I'm trying to get libfortran (all_l4.c) building for m32c, and it
> complains (eventually) that it can't add PSI (pointer) and HI
> (integer) types together. I've backtracked to the statement just
> before it's lowered to rtl, see below. Note
I'm trying to get libfortran (all_l4.c) building for m32c, and it
complains (eventually) that it can't add PSI (pointer) and HI
(integer) types together. I've backtracked to the statement just
before it's lowered to rtl, see below. Note that pointers are PSI
mode (24 bits) for this chip. My que
On 7/8/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
On Sun, 8 Jul 2007, Richard Guenther wrote:
> So type-generic is supposed to apply to scalar floating point types
> only?
So far, yes.
I don't see anything that requires or prohibits changing that for the
initial implementation. If later a
On Sun, 8 Jul 2007, Richard Guenther wrote:
> So type-generic is supposed to apply to scalar floating point types
> only?
So far, yes.
I don't see anything that requires or prohibits changing that for the
initial implementation. If later a GCC developer wants to change it to
not promote e.g. ch
On 7/8/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
On Sat, 7 Jul 2007, Joseph S. Myers wrote:
> No, that's something else entirely (a "float" old-style parameter
> declaration corresponds to a "double" argument in a prototype). It's
> convert_arguments that handles converting to prototype typ
On Sat, 7 Jul 2007, Joseph S. Myers wrote:
> No, that's something else entirely (a "float" old-style parameter
> declaration corresponds to a "double" argument in a prototype). It's
> convert_arguments that handles converting to prototype types and default
> argument promotions for arguments not
On Sat, 7 Jul 2007, Kaveh R. GHAZI wrote:
> Ok, here's a patch which adds the attribute named as you suggest and
> applies it to the relevant builtins. I'm stuck now on how and where we
> would intervene to honor it. I think we need to do it in c-decl.c:
> grokdeclarator(), where it says "promot
On Sat, 7 Jul 2007, Joseph S. Myers wrote:
> On Sat, 7 Jul 2007, Kaveh R. GHAZI wrote:
>
> > Ok, how about e.g. __attribute__ ((__type_generic__)), which would only be
> > allowed on variadic functions?
>
> I don't think we want this available to user code, just to builtins, so a
> name such as "t
On Sat, 7 Jul 2007, Kaveh R. GHAZI wrote:
> Ok, how about e.g. __attribute__ ((__type_generic__)), which would only be
> allowed on variadic functions?
I don't think we want this available to user code, just to builtins, so a
name such as "type generic" that can't be used as an identifier would
g. __attribute__ ((__type_generic__)), which would only be
allowed on variadic functions?
In addition to the isnormal (etc) builtins, we probably want to mark
"isless" and the other comparison builtins as well.
Q: Do I have to worry about languages other than the C-family?
Q: Do you reca
On Fri, 6 Jul 2007, Kaveh R. GHAZI wrote:
> So how do we detect or work around this promotion issue and discriminate
> between the case where a float is promoted because of the variadic
> prototype vs a user supplied cast or other user code?
I think we may need to tag these builtins in some way t
I have a question relating to variadic builtins and floating point
arguments. I'm trying to implement "isnormal" like so:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01292.html
Basically, I change __builtin_isnormal(x) ->
isgreaterequal(fabs(x),FP_MIN) & islessequal(fabs(x),FP_MAX)
(where FP_M
I'd like to work on using MPFR to handle builtin lgamma. The lgamma
function requires setting the global int variable "signgam" in addition to
calculating the return value of lgamma. I think I see how to do grab a
handle on signgam like so:
sg = maybe_get_identifier("signgam");
if (sg)
{
sg =
Hello,
(I'm still a newbie in gcc)
I am interested in -fwhole-program analysis (flag_whole_program) and I know
that with -O3 -fwhole-program the cgraph_nodes is cleaned (in cgraphunit.c
probably by cgraph_varpool_remove_unreferenced_decls) so that only functions
callable from main are kept (as
On Jul 15, 2005, at 5:02 PM, Ian Lance Taylor wrote:
Bharadwaj Yadavalli <[EMAIL PROTECTED]> writes:
Newer versions of C++ more or less follow the Itanium C++ ABI:
http://www.codesourcery.com/cxx-abi/abi.html
That started somewhere in gcc 3.x, though I don't know exactly when.
It starte
Bharadwaj Yadavalli <[EMAIL PROTECTED]> writes:
> Can someone please point me to a place where I can get information
> about how gcc (2.96 and later) lays out class instances? In other
> words if I examine the contents of an object pointer, is there a
> document that specifies how the contents of
Can someone please point me to a place where I can get information
about how gcc (2.96 and later) lays out class instances? In other
words if I examine the contents of an object pointer, is there a
document that specifies how the contents of the memory with relation
to the pointer correspond to the
RTH has been suggesting to use build_int_cst (etype, 0) instead.
Indeed. I was trying to minimize the change, but such cleanups are always
useful. This was also missing a protection on INTEGER_TYPE_P. I just got
a good bootstrap of Ada on x86_64 with this and a patch from Diego to fix
the o
[EMAIL PROTECTED] (Richard Kenner) writes:
> Sorry it took me so long to get to this.
>
> > You're not showing where this comes from, so it's hard to say. However
> > D.1480 is created by the gimplifier, not the Ada front end. There could
> > easily be a typing problem in the tree
Sorry it took me so long to get to this.
> You're not showing where this comes from, so it's hard to say. However
> D.1480 is created by the gimplifier, not the Ada front end. There could
> easily be a typing problem in the tree there (e.g., that of the
> subtraction) but I can't
On Tuesday 14 June 2005 21:17, Daniel Jacobowitz wrote:
> Ask me if you want either set of code.
Sure, I'd like to take a look at it.
> If you want to work on anything without duplicating effort, it behooves
> _you_ to discuss it on the mailing lists first.
Agreed. I've just recently started l
[Redirecting off gdb-discuss again]
On Tue, Jun 14, 2005 at 09:12:39PM -0400, Fred Fish wrote:
> On Tuesday 14 June 2005 10:55, Daniel Jacobowitz wrote:
> > better support for inline functions, which is already on the gdb
> > roadmap
>
> Where's the roadmap? I'm just starting to look at this ver
On Tuesday 14 June 2005 10:55, Daniel Jacobowitz wrote:
> better support for inline functions, which is already on the gdb
> roadmap
Where's the roadmap? I'm just starting to look at this very issue
and would be good to know what is planned or in progress.
Thanks.
-Fred
[Redirecting off the misnamed gdb-discuss list; please use
[EMAIL PROTECTED] instead.]
On Tue, Jun 14, 2005 at 10:22:23AM +0100, Andrew Haley wrote:
> You have the same problem with Java -- you're stepping through a Java
> program, and all of a sudden you're inside the memory allocator. What
> we
Stuart Hastings writes:
> Subject says it all.
>
> IIUC, the SSE intrinsics are made available as functions because
> that's the least-broken way to support them in a target-agnostic
> compiler. They're clearly intended to be fully inlined in normal
> usage. And they're marked "inlin
On Tue, May 03, 2005 at 06:21:11PM -0400, Richard Kenner wrote:
> As of right now, I don't think this is a VRP problem, but something wrong
> with the tree Ada produces.
>
That'd be good. If that's the case, we can make VRP assert that
the range derived from such types agrees with the type's ran
Yeah, I didn't show all of it, sorry. My patch to address this
problem includes a more detailed description
(http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00127.html).
As of right now, I don't think this is a VRP problem, but something wrong
with the tree Ada produces.
Configu
On Mon, May 02, 2005 at 09:46:59PM -0400, Richard Kenner wrote:
> You're not showing where this comes from, so it's hard to say. However
> D.1480 is created by the gimplifier, not the Ada front end. There could
> easily be a typing problem in the tree there (e.g., that of the subtraction),
> but
I am tracking an ICE in VRP that triggers only in Ada. Given
this:
1 D.1480_32 = nam_30 - 30361;
2 if (D.1480_32 <= 1) goto ; else goto ;
3 :;
4 D.1480_94 = ASSERT_EXPR ;
5 goto ();
for name D.1480_94. However, the type of D.1480 is:
(gdb) ptu
I am tracking an ICE in VRP that triggers only in Ada. Given
this:
1 D.1480_32 = nam_30 - 30361;
2 if (D.1480_32 <= 1) goto ; else goto ;
3 :;
4 D.1480_94 = ASSERT_EXPR ;
5 goto ();
When visiting statemen #4, VRP tries to create the range [-INF, 1]
for name D
> Giovanni Bajo writes:
>> Dale Johannesen <[EMAIL PROTECTED]> wrote:
>>> I do think the C++ FE needs fixing before Diego's change gets merged,
>>> though. I can make the change, but not instantly. If someone files
>>> a PR, and assigns to me, I'll get to it at some not-too-distant
>>> point.
>>
> Richard Kenner wrote:
>>It would be good to have a way to mark things as "write once, then
>>readonly" IMO. It's very common, and you can do some of the same
>>optimizations on such things that you can do on true Readonly objects.
>
> We used to do this in RTL and it caused all sorts
It would be good to have a way to mark things as "write once, then
readonly" IMO. It's very common, and you can do some of the same
optimizations on such things that you can do on true Readonly objects.
We used to do this in RTL and it caused all sorts of problems.
One is that suppos
I agree, in principle. The C++ FE should not set TREE_READONLY on
variables that require dynanmic initialization. Until now, that's not
been a problem, and it does result in better code. But, it's now
becoming a problem, and we have others way to get good code coming down
On Fri, Apr 08, 2005 at 07:57:31PM -0400, Daniel Berlin wrote:
> Some of these global properties probably belong in cgraph_var node's
> instead of shoving them into the tree structure.
I tend to agree. This would allow us to do things like find out
that the variable is read-write while compiling
>> On Fri, 2005-04-08 at 16:51 -0700, Dale Johannesen wrote:
>>> On Apr 8, 2005, at 4:40 PM, Mark Mitchell wrote:
Daniel Berlin wrote:
Your transform is correct.
The FE is not. The variable is not read only.
It is write once, then read-only.
>>>
>>> Diego, your analysis is exact
On Fri, Apr 08, 2005 at 04:40:01PM -0700, Mark Mitchell wrote:
> I do think the C++ FE needs fixing before Diego's change gets merged,
> though. I can make the change, but not instantly. If someone files a
> PR, and assigns to me, I'll get to it at some not-too-distant point.
>
PR c++/20912.
Dale Johannesen <[EMAIL PROTECTED]> wrote:
>> I do think the C++ FE needs fixing before Diego's change gets merged,
>> though. I can make the change, but not instantly. If someone files
>> a PR, and assigns to me, I'll get to it at some not-too-distant
>> point.
>
> It would be good to have a wa
On Fri, 2005-04-08 at 16:51 -0700, Dale Johannesen wrote:
> On Apr 8, 2005, at 4:40 PM, Mark Mitchell wrote:
>
> > Daniel Berlin wrote:
> >
> >> Your transform is correct.
> >> The FE is not. The variable is not read only.
> >> It is write once, then read-only.
> >
> > Diego, your analysis is exac
On Apr 8, 2005, at 4:40 PM, Mark Mitchell wrote:
Daniel Berlin wrote:
Your transform is correct.
The FE is not. The variable is not read only.
It is write once, then read-only.
Diego, your analysis is exactly correct about what is happenning.
I agree, in principle. The C++ FE should not set TREE_R
Daniel Berlin wrote:
Your transform is correct.
The FE is not. The variable is not read only.
It is write once, then read-only.
Diego, your analysis is exactly correct about what is happenning.
I agree, in principle. The C++ FE should not set TREE_READONLY on
variables that require dynanmic initi
On Fri, 2005-04-08 at 12:45 -0400, Diego Novillo wrote:
> One of the micro-optimizations I am about to merge from TCB
> involves disregarding V_MAY_DEF/V_MUST_DEF operands for read-only
> globals.
>
> So, if a symbol is marked read-only and the operand scanner
> requests a V_MAY_DEF or V_MUST_DEF
One of the micro-optimizations I am about to merge from TCB
involves disregarding V_MAY_DEF/V_MUST_DEF operands for read-only
globals.
So, if a symbol is marked read-only and the operand scanner
requests a V_MAY_DEF or V_MUST_DEF operand for it, we replace it
with a VUSE.
This works fine, except
Christophe Jaillet wrote:
In loop.c, around line 8887, shouldn't the memory allocated by alloca be
'memseted' in some way ?
Look closer, and you will see that only array values that are set are used.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
In loop.c, around line 8887, shouldn't the memory allocated by alloca be
'memseted' in some way ?
giv_array = alloca (giv_count * sizeof (struct induction *));
There is a loop just below that set some elements but not all.
But a few lines below again, ALL values of giv_array are used. I think th
76 matches
Mail list logo
