On 3/30/21 11:34 AM, Jonathan Wakely wrote:
> On Tue, 30 Mar 2021 at 11:14, Andrew Haley wrote:
>> We could just rename it to "GCC", in much the same way that Acorn Risc
>> Machine became Advanced Risc Machines, then just "Arm". But I'd much
>&
aybe you
> might suggest a new name for the project (~:
We could just rename it to "GCC", in much the same way that Acorn Risc
Machine became Advanced Risc Machines, then just "Arm". But I'd much
prefer that the FSF got its house in order.
--
Andrew Haley (he/him)
J
faster.
>
> IIRC, idiv requires that the quotient fit in 32 bits, while your C code
> doesn't. (1LL << 60) / 3 would cause an error with idiv.
Isn't that an integer overflow, which is undefined behaviour?
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK
be far more
expensive than atomic CAS. It may well be that on N1 an LDX
followed quickly by an STX fails frequently under high contention,
which it really should not do.
It looks like the sample code provided is fantastically highly-
contended, which is IMVHO a perverse thing to optimize for.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 12/9/19 5:03 PM, Nicholas Krause wrote:
>> https://gcc.gnu.org/projects/cxx-status.html#cxx11
> I'm asking of what support exists in the gcc codebase itself not for other
> projects using gcc.
That is what you got.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red H
GCC as a builtin. It's fast, simple, and
widely used. These days you might use variable-length arrays instead,
which are at least portable.
Is there some problem that you want to solve?
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Is there some kind of magic TLS optimization that
> can happen for certain variables on aarch64? I'm trying
> to understand how it could know the offset like
> it appears to do in the code.
https://www.fsfla.org/~lxoliva/writeups/TLS/paper-lk2006.pdf
--
Andrew Haley
Java P
t this until next
> weekend.
>
> In the meantime, comments are still welcome :-)
Did you look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
This was the change that caused this behaviour.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 3/22/19 10:20 AM, Allan Sandfeld Jensen wrote:
> On Freitag, 22. März 2019 11:02:39 CET Andrew Haley wrote:
>> On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote:
>>> From having fixed UBSAN warnings, I have seen many cases where undefined
>>> behavior was performed, b
undefined behaviour commonplace among C programmers?
There's nothing in the standard to justify it: any expression which contains
UB is undefined.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 3/21/19 8:53 AM, Moritz Strübe wrote:
> Hey.
>
> Am 20.03.2019 um 18:36 schrieb Andrew Haley:
>> On 3/20/19 2:08 PM, Moritz Strübe wrote:
>>> Ok, I played around a bit. Interestingly, if I set
>>> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the
int limit_tmp = i * 5;
for (int i = start * 5; i < limit_tmp; i += 5) {
foo(i);
}
If you answered "Yes, GCC should be allowed to do this", would you
want a warning? And how many such warnings might there be in a typical
program?
--
Andrew Haley
Java Platform Lead Engineer
Red Hat
feature that absolutely requires user documentation.
I don't agree. Sometimes vectorization is critical. It would be nice
to have a warning which would fire if vectorization failed. That would
surely help the OP.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 10/08/2018 07:38 PM, Paul Koning wrote:
>
>
>> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote:
>>
>> On 10/08/2018 06:20 PM, Michael Matz wrote:
>>> Only if you somewhere visibly add accesses to *i and *j. Without them you
>>> only have the "
> pointers in disguise and hence be in fact only 1-aligned. I.e. there's
> nothing in your small example program from which GCC can infer that those
> two global pointers are in fact 2-aligned.
So all you'd actually have to say is
void f1(void)
{
*i; *j;
__builtin_
a pointer to T to a pointer to
some union type, magic will happen. It won't work, unless the object
stored in the memory at that address was stored as the union type.
Do not lie to the compiler or it will get its revenge.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https
On 07/01/2018 03:19 PM, Mahmood Naderan via gcc wrote:
> Is there any builtin function in C which prints the virtual address
> of functions including the main? I see __builtin_return_address()
> but that returns the “return address”.
#include
int main() {
printf("%p\n", m
rmal
number.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
tion after initialization but with
> volatile it does not.
That's what should happen on x86.
> So I think it might not provide the same guarantees.
I think it does.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 07/05/18 18:08, Indu Bhagat wrote:
[Trying to get some feedback. I earlier posted on gcc-help a week ago]
In tree.def -
/* Minimum and maximum values. When used with floating point, if both
operands are zeros, or if either operand is NaN, then it is unspecified
which of the two oper
On 04/25/2018 03:04 PM, Jonathan Wakely wrote:
> On 25/04/18 14:59 +0100, Andrew Haley wrote:
>> On 04/25/2018 02:56 PM, Jason Merrill wrote:
>>> The warning by default seems sufficient to me.
>>
>> Yes. We've been bitten by this a few times, with mysterious cra
On 04/25/2018 02:56 PM, Jason Merrill wrote:
> The warning by default seems sufficient to me.
Yes. We've been bitten by this a few times, with mysterious crashes.
I'm not sure it even makes sense only to be a warning, but I guess
that's up to the C++ TC.
--
Andrew Haley
t of main, the
effect is equivalent to a return with operand 0 (see also 18.3).
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 10/01/18 14:33, Jakub Jelinek wrote:
> On Wed, Jan 10, 2018 at 02:30:39PM +0000, Andrew Haley wrote:
>> I don't seem to have write access to bugs in GCC Bugzilla. I'm pretty
>> sure I used to have it. Who do I contact? Thanks.
>
> You need to use the @gc
I don't seem to have write access to bugs in GCC Bugzilla. I'm pretty
sure I used to have it. Who do I contact? Thanks.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 03/12/17 10:50, Jakub Jelinek wrote:
> On Sat, Dec 02, 2017 at 05:00:23PM +0000, Andrew Haley wrote:
>> On 02/12/17 14:04, Liu Hao wrote:
>>>
>>> 0) What is the magical `@tpoff` suffix supposed to do? The `@ntpoff` and
>>> `@dtpoff` things are documented in
d thereafter. How is LD supposed to
> associate the section containing the initializer with the symbol of
> object being initialized, without disordering?
>
> Any help will be appreciated.
Have you read
https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt
?
--
Andrew H
On 19/10/17 14:04, Sebastian Huber wrote:
> On 19/10/17 14:18, Andrew Haley wrote:
>> On 19/10/17 13:10, Jonathan Wakely wrote:
>>> There are no atomic operations on atomic objects here, so the fence
>>> doesn't synchronize with anything.
>> Really? This se
ed-with all non-atomic
and relaxed atomic loads from the same locations made in thread B
after F.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_1;
[100.00%]:
_1 = m_2(D) * 4711;
message = _1;
__atomic_thread_fence (3);
ready = 1;
return;
}
It looks like a bug in the lowering pass.
;; __atomic_thread_fence (3);
is lowered to
(nil)
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 18/09/17 10:48, Florian Weimer wrote:
> Is this a property of the char type, or would other types work as well,
> for example, double or long double?
It has to be a character type, I believe.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EA
27;t know who done it.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
ould abandon the eternal drive for more
and more optimizations, back off, and concentrate on simplicity and
robustness at the expens of ultimate code quality. Should we? It
would take courage, and there will be an eternal pressume to improve
code. And, of course, we'd risk someone forking GC
ble sections? Is there any way to avoid this?
> Any ideas?
On ARM, PC-relative loads have a fairly short range. So:
float d() {
return 3.141592653589;
}
d:
ldr s0, .LC0
ret
.align 2
.LC0:
.word 1078530011
--
Andrew Haley
Java Platform Lead Engine
static uint32_t calc_16bit_checksum_part(uint8_t* buf, int len,
uint32_t ret) {
struct ui16{
uint16_t d;
};
ui16 *ptr = (ui16*)buf;
There's no need for any of this messing about with pointer casts, as has
been explained.
--
Andrew Haley
Java Platform Lead E
+, but if you really want to do this kind
of thing, use -fno-strict-aliasing.
See also
http://www.microhowto.info/howto/calculate_an_internet_protocol_checksum_in_c.html
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 28/02/17 06:38, Eyal Itkin wrote:
> However, in signed integers, the logical meaning of any relation check
> is only the theoretical meaning of the order relation between the
> numbers in the group Z. Meaning that in a purely theoretical manner "a
> + b < c" is a relation order that is equivalen
On 22/02/17 05:52, R0b0t1 wrote:
> I have found GCJ to be one of the best methods for bootstrapping
> OpenJDK. No other method of adding support for new architectures that
> does not involve working closely with OpenJDK upstream is known to me.
That doesn't matter any more because OpenJDK has full
On 23/01/17 16:11, Joshua Kinard wrote:
> So now the question is why stack-probing kills this machine on generic MIPS
> code that its smaller cousin is seemingly unaffected by. I do know that IP27
> has a different set of memory initialization routines in the MIPS code, so is
> it possible that, a
On 23/01/17 15:26, Joshua Kinard wrote:
> I am not sure what this lone store-doubleword instruction is exactly doing,
> nor
> can I locate where in the gcc MIPS code it is being generated from.
It's a stack probe, making sure that there is enough stack space. Its
only purpose is to provide a SE
On 18/12/16 02:33, Seima Rao wrote:
> Precisely, stuffs like GENERIC, GIMPLE, RTL, gas(inline assembly),
> GCC extensions internals, ... and gnu's own debugging tied to gcc
> (if such exist nowadays), ... are not documented in a specification
> driven way.
That's interesting. Can
On 28/10/16 04:03, Ian Lance Taylor wrote:
> On Thu, Oct 27, 2016 at 6:08 AM, Anthony Green wrote:
>> Is it still important that libffi be included in the GCC tree?
>
> [ Replying again as last message was bounced as HTML--sorry for the
> duplication.]
>
> libffi is used by libgo, for much the s
On 27/10/16 13:55, Matthias Klose wrote:
> With the removal of libgcj, the only user of libffi in GCC is libgo, however
> there is now no maintainer listed anymore for libffi in the MAINTAINERS file,
> and the libffi subdir is a bit outdated compared to the libffi upstream
> repository (got aware o
On 12/09/16 20:41, Igor Shevlyakov wrote:
> It would be beneficial to make the behaviour consistent between
> those 2 cases.
You've got two cases of undefined behaviour. What benefit
is there from making two cases of UB consistent with each other?
It's not worth the effort of changing the compil
On 26/07/16 15:37, Warren D Smith wrote:
> --the reason I am suggesting this to this forum, is I probably am not capable
> of
> recoding GCC myself.
> Why not learn from your own history, and do that again, with these two
> extensions?
> (And in the case of uint4_t, it actually would not even BE
On 26/07/16 14:31, Warren D Smith wrote:
> However, why not provide access to double-precision multiply and
> add-with-carry (subtract with borrow? shift-left?) in the same fashion?
>twofer x = mul(a,b); would cause x.hi and x.lo to be computed.
>twofer x = addwithcarry(a,b) ditto.
On 25/07/16 14:17, fedor...@mail.ru wrote:
> I build for arm cpu. How write this function? Where I can see example
> implementation? GCC builded with multilib support.
If your ARM cpu has only one core, the function can be empty. If it
has more than one core, then you must tell GCC which model o
On 25/07/16 12:37, fedor...@mail.ru wrote:
> GCC 6.1.0 inserts call to __sync_synchronize and linker fails with
> error: undefined reference to `__sync_synchronize'. If this is bug I
> can send preprocessed file.
This is something that you can provide yourself. If it's a
single-core cpu the func
On 04/07/16 14:43, Jonathan Wakely wrote:
> It doesn't matter how much warning people have to fix such things,
> most of them won't do it. Then at the last minute some poor person has
> to spend days or weeks going through other people's code fixing all
> the problems...
...and breaking everything
On 22/06/16 09:59, Florian Weimer wrote:
> On 06/20/2016 07:40 PM, Andrew Haley wrote:
>> On 20/06/16 18:36, Michael Matz wrote:
>>> I see zero gain by deprecating them and only churn. What would be the
>>> advantage again?
>>
>> Correctness. It is very l
On 21/06/16 17:43, Jeff Law wrote:
> I think there's enough resistance to deprecating basic asms within a
> function that we should probably punt that idea.
>
> I do think we should look to stomp out our own uses of basic asms
> within functions just from a long term maintenance standpoint.
>
>
Hi,
On 21/06/16 13:08, Michael Matz wrote:
> On Tue, 21 Jun 2016, Andrew Haley wrote:
>
>>> As said in the various threads about basic asms, all correctness
>>> problems can be solved by making GCC more conservative in handling
>>> them (or better said
Hi,
On 20/06/16 19:01, Michael Matz wrote:
> On Mon, 20 Jun 2016, Andrew Haley wrote:
>
>> On 20/06/16 18:36, Michael Matz wrote:
>>> I see zero gain by deprecating them and only churn. What would be the
>>> advantage again?
>>
>> Correctness.
>
On 20/06/16 18:36, Michael Matz wrote:
> I see zero gain by deprecating them and only churn. What would be the
> advantage again?
Correctness. It is very likely that many of these basic asms are not
robust in the face of compiler changes because they don't declare
their dependencies and therefo
On 20/06/16 15:52, Segher Boessenkool wrote:
> On Mon, Jun 20, 2016 at 03:49:19PM +0100, Andrew Haley wrote:
>> On 20/06/16 15:42, Segher Boessenkool wrote:
>>> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
>>>> On 20/06/16 14:50, Segher Boessenkoo
On 20/06/16 15:42, Segher Boessenkool wrote:
> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
>> On 20/06/16 14:50, Segher Boessenkool wrote:
>>> If basic asm is deprecated, that means some time later it will be
>>> removed, at which time an asm without :
On 20/06/16 14:50, Segher Boessenkool wrote:
> If basic asm is deprecated, that means some time later it will be
> removed, at which time an asm without : can be used as extended asm
Not exactly: it'd be an asm with no inputs, no outputs, and no
clobbers i.e. no effects.
Andrew.
On 20/06/16 08:00, Andrew Pinski wrote:
> + /* Acceptable. */
> + asm (" "); /* { dg-warning "Deprecated: asm in function without
> extended syntax" } */
This is incorrect English. It should be
"Deprecated: asm without extended syntax in function"
because it's the asm that is missing the e
On 05/20/2016 10:02 AM, Florian Weimer wrote:
> On 05/20/2016 10:30 AM, lh mouse wrote:
>> Implicit function declarations result in warnings since C99 or GNU99 and
>> '-pedantic-errors' turns them into errors.
>> The same goes for implicit return types.
>
> The warnings typically do not stop the
On 05/05/2016 07:56 PM, Antonio Diaz Diaz wrote:
> Take this example http://gcc.gnu.org/ml/gcc-patches/2016-03/msg00261.html
>
> The user sees this:
>
>if (flagA) // GUARD
> foo (0); // BODY
> #if SOME_CONDITION_THAT_DOES_NOT_HOLD
>if (flagB)
> #endif
> foo (1); // NEXT
Sure
On 17/04/16 17:58, J a h a n z e b F a h i m wrote:
> i am a java developer, i want to install gnu java compiler on LINUX
> 7.2 for testing purpose. i already have gcc version 4.8.5 20150623
> (Red Hat 4.8.5-4) (GCC) in my machine. now i want to add gcj in it.
> how can i install it?
It's going t
On 27/03/16 06:57, Michael Clark wrote:
> GCC, Clang folk, any ideas on why there is a stack spill for a
> volatile register argument passed in esi? Does volatile force the
> argument to have storage allocated on the stack? Is this a corner
> case in the C standard? This argument in the x86_64 cal
On 27/02/16 11:53, Jakub Jelinek wrote:
> On Sat, Feb 27, 2016 at 10:39:59AM +0000, Andrew Haley wrote:
>> On 26/02/16 21:28, Bradley Lucier wrote:
>>> Any advice on how to proceed? I'd be willing to write and test the few
>>> lines of code myself if I knew w
On 26/02/16 21:28, Bradley Lucier wrote:
> Any advice on how to proceed? I'd be willing to write and test the few
> lines of code myself if I knew where to put them.
The best thing, rather than warning, would be to define this
conversion as a GCC extension and implement it consistently
everywher
On 02/16/2016 01:16 PM, Jakub Jelinek wrote:
>> > Can someone please tell me Chapter and Verse in the standard, please?
>> > Then I can close this one.
> I'd think [basic.life] describes this.
For the record, I found it in C++98 [class.cdtor]:
For an object of non-POD class type ... before the
I'm fixing a bug which involves initialization of a field of an object
in its placement new function before the constructor is called. This
is falling foul of DSE, which deletes the field initialization.
I see this:
@item -fno-lifetime-dse
@opindex fno-lifetime-dse
In C++ the value of an o
On 02/02/2016 05:41 PM, Manuel López-Ibáñez wrote:
> Everything is possible! Not sure how hard it would be, though. As
> said, GJC, the Java FE, was doing something similar sometime ago, but
> it has perhaps bit-rotted now.
It is doing something the other way around: bytecode to Gimple.
Andrew.
On 30/12/15 15:33, Georg-Johann Lay wrote:
> Some parts of the compiler use the address of objects to compute
> hashes, but I don't remember which part(s) actually do this. That
> technique can lead to different code for different runs of the
> compiler even on the same system. This is hard to r
On 17/12/15 01:41, David Wohlferd wrote:
> On the contrary, I would be surprised to learn that there are ANY
> compilers (other than clang) that support gcc's extended asm format.
Prepare to be surprised: Sun Studio compilers seem to support it
just fine.
Andrew.
On 13/12/15 06:15, David Wohlferd wrote:
>
> However breakage and performance issues can still result solely from
> adding memory clobbers.
Breakage? Really?
> And as I mentioned, "just memory clobber" may
> not be the behavior people expect. And if we aren't solving that, might
> there be
On 11/12/15 22:18, David Wohlferd wrote:
> And here are the three solutions that have been proposed:
>
> Solution 1:
> Just document the current behavior of basic asm.
>
> People who have written incorrect code can be pointed at the text and
> told to fix their code. People whose code is damag
On 11/29/2015 11:53 PM, David Wohlferd wrote:
>
> Trying to guess what people might have been expecting is a losing game.
We have to do it all the time.
> There is a way for people to be clear about what they want to clobber,
> and that's to use extended asm. The way to clear up the ambiguit
On 11/25/2015 06:25 PM, Martin Sebor wrote:
> The motivating example in the paper suggests that many C++
> programmers expect a left to right order of evaluation here
> due to the commonality of constructs like chains of calls.
Sure, I often see
foo.bar(1).bar(2).bar(3), etc.
but does anyone a
On 25/11/15 02:11, David Wohlferd wrote:
> The 'fix' I am proposing is to give warnings for every use of basic asm
> inside functions (top-level asm is not a problem).
I'm not sure that's such a great idea on its own.
My suggestion:
1. Clobber memory.
2. Document a rule which says that all r
On 23/11/15 23:01, Jason Merrill wrote:
> There's a proposal working through the C++ committee to define the order
> of evaluation of subexpressions that previously had unspecified ordering:
>
> http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf
>
> I agree with much of this, bu
On 23/11/15 21:02, David Wohlferd wrote:
>> On 11/23/2015 2:04 AM, Andrew Haley wrote:
>> > My warning still holds: there are modes of compilation on some
>> > machines where you can't clobber all registers without causing reload
>> > failures. This is why Je
On 21/11/15 12:56, David Wohlferd wrote:
> So, what now?
>
> While I'd like to take the big step and start kicking out warnings for
> non-top-level right now, that may be too bold for phase 3. A more
> modest step for v6 would just provide a way to find them (maybe
> something like -Wnon-top-b
On 20/11/15 10:37, David Wohlferd wrote:
> The intent for 24414 is to change basic asm such that it will become
> (quoting jeff) "an opaque blob that read/write/clobber any register or
> memory location." Such being the case, "memory" is not sufficient:
>
> #define CLOBBERALL "eax", "ebx", "ecx
On 20/11/15 01:23, David Wohlferd wrote:
> I tried to picture the most basic case I can think of that uses
> something clobber-able:
>
> for (int x=0; x < 1000; x++)
>asm("#stuff");
>
> This generates very simple and highly performant code:
>
> movl$1000, %eax
> .L2:
>
On 17/11/15 05:55, David Wohlferd wrote:
> How much pessimism are we talking here? Wouldn't clobbering everything
> effectively force the reloading of (some? most? all?) registers? And
> more memory will be needed to store things that used to just require
> registers?
No, really not. It only
On 10/20/2015 05:22 PM, Jeff Law wrote:
> On 10/20/2015 10:15 AM, Andrew Haley wrote:
>>> But in that case, what do we guarantee.
>>>
>>> We certainly don't guarantee that those objects will be in their
>>> requested register at any point other than at
On 10/20/2015 05:12 PM, Jeff Law wrote:
> On 10/20/2015 10:05 AM, Andrew Haley wrote:
>> On 10/20/2015 05:00 PM, Jeff Law wrote:
>>> But the technical reality is I can't see a use outside the extended asm.
>>
>> I can. In the past (and probably still today) GC
On 10/20/2015 05:00 PM, Jeff Law wrote:
> But the technical reality is I can't see a use outside the extended asm.
I can. In the past (and probably still today) GCC did an awful job of
allocating registers in a large function. This was visible in a
bytecode interpreter, where the programmer kno
On 13/10/15 08:55, Abhishek Aggarwal wrote:
> The return address of the calling function is still at +4 byte offset
> wrt to new frame pointer (%ebp) of 'main' function. However, now the
> first argument of 'main' function may not be at +8 byte offset wrt to
> the new frame pointer of the 'main' fu
On 03/10/15 21:41, Matthijs van Duin wrote:
> Anyhow, it only took four years, but you can now throw
> NullPointerExceptions on ARM. Enjoy. ;-)
Ok, nice. :-)
Do you have GCC copyright assignment, and will you turn this into
a patch which can be applied?
Thanks,
Andrew.
On 07/28/2015 04:40 PM, Paulo Matos wrote:
> The block skips the test for ((unsigned int) xx << 1 == 0 && yy == -1),
> should we skip it if they're both zero as well?
Yes. It's undefined behaviour. If we don't want to invoke nasal
daemons we shouldn't do this.
Andrew.
On 07/10/2015 07:35 PM, Jeff Law wrote:
> I wonder how much overlap there is between this need and what we're
> going to need to do for resumable functions which are being discussed in
> the ISO C++ standards meetings.
A considerable amount, I'll be bound.
Andrew.
On 09/07/15 23:17, Basile Starynkevitch wrote:
> (this is triggered by a question on the Ocaml mailing list asking about
> SystemZ backend in Ocaml; SystemZ is today a backend for GCC & probably
> GCCJIT)
>
> We might want to support better good garbage collection schemes in GCC,
> particulari
On 06/24/2015 03:12 PM, Andrew Senkevich wrote:
> Can anybody tell something about this difference in drivers?
It's a UNIX tradition to require -lm for the floating-point
library in C programs. It doesn't make much sense now, but it's
hard to change it.
Andrew.
On 05/20/2015 04:46 PM, Will Deacon wrote:
> I'm not sure... you'd require the compiler to perform static analysis of
> loops to determine the state of the machine when they exit (if they exit!)
> in order to show whether or not a dependency is carried to subsequent
> operations. If it can't prove
On 05/20/2015 01:04 PM, mark maule wrote:
> Is this one of those areas where if
> there's a bug in the code all bets are off and your mileage may vary?
Yes. Do not access beyond the end of an array: daemons may fly out
of your nose. [1]
Andrew.
[1]
https://groups.google.com/forum/?hl=en#!msg/
On 05/19/2015 04:14 PM, mark maule wrote:
> Thanks again Martin. I started going down that road yesterday, and got
> lost in the forest of options. What I was looking for was some option
> that would tell me what was being done with dgHandle specifically. I
> played around with -fopt-info-al
On 04/16/2015 02:22 PM, Manuel López-Ibáñez wrote:
> On 16/04/15 10:04, Andrew Haley wrote:
>> On 16/04/15 06:12, Mikhail Maltsev wrote:
>>> So, I want to create a similar page in GCC's internal docs, but I don't
>>> know what should be included (i.e. did I m
On 16/04/15 06:12, Mikhail Maltsev wrote:
> So, I want to create a similar page in GCC's internal docs, but I don't
> know what should be included (i.e. did I miss something important, or
> did I include something obsolete), so I ask for some assistance.
The real challenge here is not generating t
On 11/04/15 04:08, Kumar Aditya wrote:
> I am new user of Linux. I have RHEL 6.0 installed and want to run C++
> on my system but I do not know how.
yum install gcc-c++.
Andrew.
On 04/02/2015 12:43 PM, Florian Weimer wrote:
>
> But it is dubious to require that, say, strdup ("example") returns a
> pointer which is 16-byte-aligned, too.
>
> What is missing, it seems to me, is the qualification that for the
> pointer returned by malloc, the alignment requirements only of t
On 04/02/2015 09:46 AM, Florian Weimer wrote:
> On 04/02/2015 10:40 AM, Andrew Haley wrote:
>
>> So, max_align_t is an object type, and therefore malloc returns a
>> pointer suitable for max_align_t.
>
> Then the GCC definition of max_align_t is incorrect, it should be
On 04/02/2015 09:26 AM, Florian Weimer wrote:
> On 03/23/2015 07:41 PM, Florian Weimer wrote:
>
>> Ah, I should have looked at what max_align_t actually meant. With these
>> semantics, the name is a bit confusing. I agree that requiring 64 byte
>> alignment from malloc does not make much sense.
On 02/24/2015 12:14 PM, Richard Biener wrote:
> These concerns are correct. Btw, as an answer to Steve - within
> -funsafe-math-optimizations FMA_EXPR basically can be either
> fused or not fused (but yes, bad as to Josephs concern).
> So you could guard the pattern by flag_unsafe_math_optimizatio
On 02/20/2015 11:06 AM, Florian Weimer wrote:
> On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
>> H, Passing the additional option in user code would be one thing,
>> but what about library code? E.g., using memcpy (either explicitly or
>> implicitly for a structure copy)?
>
> The memcpy pr
1 - 100 of 1072 matches
Mail list logo
