> On Jul 26, 2016, at 2:07 PM, Warren D Smith wrote:
>
> To the guy who falsely claimed MIPS fails to provide an add with carry
> instruction,
> a google search in 1 minute finds this:
>
> stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly
>
> I defy you to find any proc
> On Jul 26, 2016, at 12:50 PM, Warren D Smith wrote:
>
> ...
> Sigh. It's really hard to get compiler and language guys to do anything.
I find it puzzling that you appear to think that insulting your audience is the
best way to influence them.
> ...
> There is absolutely no good reason why
> On May 8, 2016, at 6:27 PM, David Wohlferd wrote:
>
> Looking at the v6 release criteria (https://gcc.gnu.org/gcc-6/criteria.html)
> there are about a dozen supported platforms.
>
> Looking at the Machine Constraints docs
> (https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html), ther
> On Mar 28, 2016, at 8:11 AM, Florian Weimer wrote:
>
> ...
> The problem is that “reading” is either not defined, or the existing
> flatly contradicts existing practice.
>
> For example, if p is a pointer to a struct, will the expression &p->m
> read *p?
Presumably the offset of m is substan
> On Mar 18, 2016, at 12:53 PM, Paulo Matos wrote:
>
>
>
> On 18/03/16 15:02, Jonathan Wakely wrote:
>>
>> It's probably crashing because it's too large, so if you reduce it
>> then it won't crash.
>>
>
> Would be curious to see what's the limit though, or if it depends on the
> machine he'
> On Mar 14, 2016, at 12:05 PM, C Bergström wrote:
>
> I don't speak with any community authority - I think your test tool is
> misconfigured then. I don't see any pragmatic reason to generate such
> a test. It's unlikely to mirror any real world code and artificial
> test cases like this, at be
> On Mar 14, 2016, at 11:31 AM, Andrey Tarasevich
> wrote:
>
> Hi,
>
> I have a source file with 700k lines of code 99% of which are printf()
> statements. Compiling this test case crashes GCC 5.3.0 with segmentation
> fault.
> Can such test case be considered valid or source files of size
> On Jan 8, 2016, at 6:32 AM, Jakub Jelinek wrote:
>
> On Fri, Jan 08, 2016 at 12:24:49PM +0100, Eric Botcazou wrote:
>>> See some existing PR. The GCC middle-end cannot assume that pointers
>>> are aligned according to their type (while at least the C language would
>>> support that notion).
>
> On Dec 15, 2015, at 5:22 PM, David Wohlferd wrote:
>
> On 12/14/2015 1:53 AM, Andrew Haley wrote:
>> > This just seems like another argument for deprecating basic asm and
>> > pushing people to extended.
>> Yes. I am not arguing against deprecation. We should do that.
>
> You know, there a
> On Dec 15, 2015, at 7:52 AM, Bernd Schmidt wrote:
>
> On 12/14/2015 09:10 AM, Segher Boessenkool wrote:
>> That, and adding a memory clobber degrades performance for a lot of
>> existing basic asm that does not expect the clobber, e.g. asm(""),
>> asm("#"), asm("nop"), ...
>
> I wonder about
> On Dec 12, 2015, at 4:51 AM, Andrew Haley wrote:
>
> ...
> You've missed the most practical solution, which meets most common
> usage: clobber memory, but not registers. That allows most of the
> effects that people intuitively want and expect, but avoids the
> breakage of register clobbers.
> On Dec 3, 2015, at 12:29 AM, Bernd Edlinger wrote:
>
>> ...
>> If the goal is to order things wrt x, why wouldn't you just reference x?
>>
>> x = 1;
>> asm volatile("nop":"+m"(x));
>> x = 0;
>>
>
> Exactly, that is what I mean. Either the asm can use memory clobber
> or it can use ou
> On Nov 29, 2015, at 6:53 PM, David Wohlferd wrote:
>
>
>
> On 11/28/2015 10:30 AM, paul_kon...@dell.com wrote:
>>> On Nov 28, 2015, at 2:02 AM, Bernd Edlinger
>>> wrote:
>>>
>>> ...
>>> Well, I start to think that Jeff is right, and we should treat a asm ("")
>>> as if it
>>> were asm vo
> On Nov 28, 2015, at 2:02 AM, Bernd Edlinger wrote:
>
> ...
> Well, I start to think that Jeff is right, and we should treat a asm ("") as
> if it
> were asm volatile ("" ::: ) but if the asm ("nonempty with optional %") we
> should
> treat it as asm volatile ("nonempty with optional %%" :::
> On Nov 25, 2015, at 1:25 PM, Martin Sebor wrote:
>
> On 11/24/2015 02:55 AM, Andrew Haley wrote:
>> 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:
> On Nov 24, 2015, at 12:49 PM, Ian Lance Taylor wrote:
>
> On Tue, Nov 24, 2015 at 8:58 AM, wrote:
>>
>> I'm really concerned with loosening the meaning of basic asm. I
>> wish I could find the documentation that says, or implies, that it
>> is a memory clobber. And/or that it is implicitl
> On Nov 23, 2015, at 8:39 PM, David Wohlferd wrote:
>
> On 11/23/2015 1:44 PM, paul_kon...@dell.com wrote:
>>> On Nov 23, 2015, at 4:36 PM, David Wohlferd wrote:
>>>
>>> ...
The more I think about it, I'm just not keen on forcing all those
old-style asms to change.
>>> If you mean
> On Nov 23, 2015, at 4:36 PM, David Wohlferd wrote:
>
> ...
>> The more I think about it, I'm just not keen on forcing all those old-style
>> asms to change.
>
> If you mean you aren't keen to change them to "clobber all," I'm with you.
> If you are worried about changing them from basic to
> On Nov 20, 2015, at 3:01 PM, Jeff Law wrote:
>
> On 11/20/2015 07:56 AM, Segher Boessenkool wrote:
>
> When basic asm changes, I expect that having a way to "just do what it
> used to do" is going to be useful for some people.
24414 says the documented behaviour hasn't been true
> On Nov 20, 2015, at 1:24 PM, Jeff Law wrote:
>
> On 11/20/2015 06:05 AM, Richard Henderson wrote:
>
>> ...
>> It seems to me that it would be better to remove the feature, forcing
>> what must be an extremely small number of users to audit and update to
>> extended asm.
> That might be a litt
> On Sep 16, 2015, at 4:38 AM, Richard Biener
> wrote:
>
> On Tue, Sep 15, 2015 at 7:09 PM, Florian Weimer wrote:
>> ...
>> Unlike Subversion branch deletion, Git branch deletion is permanent,
>> so this might not be the best option.
>
> We could have a 2nd git repository just containing dele
> On Sep 9, 2015, at 1:54 PM, David Edelsohn wrote:
>
> On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg wrote:
>
>> The ABI dictates basically everything you see. The call to
>> explicit_bzero has forced the compiler to *create* a second copy of
>> the variable `k` on the stack, just so it can
> On Sep 9, 2015, at 12:36 PM, Zack Weinberg wrote:
>
> ...
> I think the ideal feature addition to address this would be
>
>void safe(void)
>{
>struct key __attribute__((sensitive)) k = get_key();
>use_key(k);
>}
That certainly is a cleaner answer. What is attract
> On Aug 20, 2015, at 4:24 PM, Jason Merrill wrote:
>
> On 08/20/2015 04:22 PM, paul_kon...@dell.com wrote:
>> Let's make sure the procedures that people are supposed to follow are
>> clearly documented. I recently went looking for the equivalent in the
>> binutils/gdb project and it doesn't
> On Aug 20, 2015, at 4:09 PM, Jason Merrill wrote:
>
> On 08/20/2015 02:23 PM, Jeff Law wrote:
>> ...As far as the trunk and release branches, are there any best practices
>> out there that we can draw from? Obviously doing things like
>> push-rebase-push is bad. Presumably there's others.
>
> On May 20, 2015, at 1:22 PM, Jakub Jelinek wrote:
>
> On Wed, May 20, 2015 at 05:19:28PM +, paul_kon...@dell.com wrote:
>>
>>> On May 20, 2015, at 1:00 PM, H.J. Lu wrote:
>>>
>>> By default, alignment of DImode and DFmode is set to 8 bytes.
>>
>> When did that change? I know it was 4
> On May 20, 2015, at 1:00 PM, H.J. Lu wrote:
>
> By default, alignment of DImode and DFmode is set to 8 bytes.
When did that change? I know it was 4 in the past, unless you specifically
passed a compile switch to make it 8.
paul
> On Apr 17, 2015, at 9:14 AM, Peter Sewell wrote:
>
> Dear gcc list,
>
> we are trying to clarify what behaviour of C implementations is
> actually relied upon in modern practice, and what behaviour is
> guaranteed by current mainstream implementations (these are quite
> different from the ISO
> On Mar 11, 2015, at 8:53 PM, David Wohlferd wrote:
>
>>> ...
>>> I would agree that one should avoid it. I'd be wary of removing it
>>> from GCC at this point since it might break working code.
>> It certainly would. It’s not all that common, but I have seen this done in
>> production code.
> On Mar 11, 2015, at 7:19 PM, Ian Lance Taylor wrote:
>
> On Wed, Mar 11, 2015 at 3:58 PM, David Wohlferd
> wrote:
>>
>> Why does gcc allow you to specify clobbers using numbers:
>>
>> asm ("" : : "r" (var) : "0"); // i386: clobbers eax
>>
>> How is this better than using register names?
> On Feb 20, 2015, at 12:01 PM, Jeff Law wrote:
>
> ...
> Regardless, the right thing to do is to disable elimination of NULL pointer
> checks on targets where page 0 is mapped and thus a reference to *0 may not
> fault. In my mind this is an attribute of both the processor (see H8 above)
>
> On Feb 20, 2015, at 12:01 PM, Jeff Law wrote:
>
> On 02/20/15 04:43, Jonathan Wakely wrote:
>>> ...
>>
>> I'm inclined to agree.
>>
>> Most developers aren't aware of the preconditions on memcpy, but GCC
>> optimizes aggressively based on those preconditions, so we have a
>> large and potent
> On Feb 6, 2015, at 5:28 AM, Andrew Haley wrote:
>
> On 02/06/2015 10:18 AM, Hans-Peter Nilsson wrote:
>> ...
>> Not sure what's not understood. IIUC you want to disable LTO
>> when building gcc natively on Android? As LTO is considered a
>> "language",
>
> ???
>
> LTO is considered a "lang
> On Jan 13, 2015, at 7:44 AM, Alexander Monakov wrote:
>
> On Tue, 13 Jan 2015, Pengfei Yuan wrote:
>> I use perf with rbf88:k,rff88:k events (Haswell specific) to profile
>> the taken rate of conditional branches in the kernel. Here are the
>> results:
> [...]
>>
>> The results are very stran
> On Jan 5, 2015, at 4:11 PM, DJ Delorie wrote:
>
>
>> To try to generalize from that: it looks like the operating
>> principle is that an insn that expands into multiple references to a
>> given operand isn’t volatile-safe, but one where there is only a
>> single reference is safe?
>
> No, if
The “news” section first link points to "https://gcc.gnu.org/gcc-5/“ which
comes up “forbidden”. The other release links seem to be fine.
paul
> On Jan 5, 2015, at 1:47 PM, DJ Delorie wrote:
>
>
>> One question: do you have an example of a non-volatile-safe machine so
>> I can get a feel for the problems one might encounter? At best I can
>> imagine a machine that optimizes "add 0, [mem]" to avoid the
>> read/write, but I'm not aware
> On Jan 5, 2015, at 1:24 PM, DJ Delorie wrote:
>
>
>> What is involved with the auditing?
>
> Each pattern that (directly or indirectly) uses general_operand,
> memory_operand, or nonimmediate_operand needs to be checked to see if
> it's volatile-safe. If so, you need to change the predicate
> On Dec 30, 2014, at 1:32 PM, Matt Godbolt wrote:
>
> On Tue, Dec 30, 2014 at 5:05 AM, Torvald Riegel wrote:
>> I agree with Andrew. My understanding of volatile is that the generated
>> code must do exactly what the abstract machine would do.
>
> That makes sense. I suppose I don't understa
> On Dec 29, 2014, at 2:01 PM,
> wrote:
>
> I would bug this but bugz says to report things under “bootstrap” only if
> they are long lived failures, and I don’t know if this is.
>
> Just tried to build on my Mac OS 10.10 system, plain native build. It fails
> in libgcc2 due to stdio.h not
I would bug this but bugz says to report things under “bootstrap” only if they
are long lived failures, and I don’t know if this is.
Just tried to build on my Mac OS 10.10 system, plain native build. It fails in
libgcc2 due to stdio.h not found. A cross-build from the same source tree
(pdp11
> On Dec 27, 2014, at 1:40 PM, Andrew Haley wrote:
>
> On 27/12/14 18:04, Matt Godbolt wrote:
>> On Sat, Dec 27, 2014 at 11:57 AM, Andrew Haley wrote:
>
>>> if you don't need an atomic access, why do you care that it uses a
>>> read-modify-write instruction instead of three instructions? Is i
> On Dec 26, 2014, at 6:19 PM, Andrew Haley wrote:
>
> On 26/12/14 22:49, Matt Godbolt wrote:
>> On Fri, Dec 26, 2014 at 4:26 PM, Andrew Haley wrote:
>>> On 26/12/14 20:32, Matt Godbolt wrote:
Is there a reason why (in principal) the volatile increment can't be
made into a single add?
> On Dec 13, 2014, at 5:22 AM, Ajit Kumar Agarwal
> wrote:
>
> Hello All:
>
> Since the prefetch instruction have no direct consumers in the code stream,
> they provide considerable freedom to the
> Instruction scheduler. They are typically assigned lower priorities than most
> of the inst
On Sep 29, 2014, at 7:59 PM, George R Goffe wrote:
>
> Jonathan,
>
> I'll give it a try. Thanks.
>
>
> What is the problem with the mailing list software? Can't handle rich-text?
> What a pain!
I don’t know if that is true, but if so, a lot of people would argue that is a
feature. (I’m i
On Aug 6, 2014, at 2:59 PM, Paolo Carlini wrote:
> Hi,
>
> On 08/06/2014 08:48 PM, paul_kon...@dell.com wrote:
>> On Aug 6, 2014, at 2:38 PM, David Gero wrote:
>>
>>> Accessing https://gcc.gnu.org/viewvc/gcc/trunk/
>>>
>>> Says it is showing 38 files. But in fact, it shows only the first 25
On Aug 6, 2014, at 2:38 PM, David Gero wrote:
> Accessing https://gcc.gnu.org/viewvc/gcc/trunk/
>
> Says it is showing 38 files. But in fact, it shows only the first 25. As an
> example, libstdc++-v3 is missing.
>
> Same thing happens in other parts of the tree.
>
> I checked the HTML page
On May 16, 2014, at 12:25 PM, Ian Bolton wrote:
>> On Fri, May 16, 2014 at 6:34 AM, Sheheryar Zahoor Qazi
>> wrote:
>>>
>>> I am trying to provide soft-fp support to a an 18-bit soft-core
>>> processor architecture at my university. But the problem is that
>>> libgcc has not been cross-compile
On Mar 27, 2014, at 6:38 AM, Renato Golin wrote:
> On 27 March 2014 10:29, Andreas Schwab wrote:
>> Depends on what you need the value for.
>
> Mostly unwind code that uses both FP and SP, example:
But unwind code is inherently platform-dependent. Your objection to the inline
asm that refer
On Mar 5, 2014, at 10:07 AM, Richard Henderson wrote:
> On 03/04/2014 10:12 PM, Yury Gribov wrote:
Asms without outputs are automatically volatile. So there ought be zero
change
with and without the explicit use of the __volatile__ keyword.
>>>
>>> That’s what the documentation
On Mar 4, 2014, at 2:30 PM, Richard Henderson wrote:
> On 03/04/2014 01:23 AM, Richard Biener wrote:
>> Doesn't sound like a bug but a feature. We can move
>> asm ("" : : : "memory") around freely up to the next/previous
>> instruction involving memory.
>
> Asms without outputs are automatical
On Dec 6, 2013, at 5:40 AM, Umesh Kalappa wrote:
> Hi all,
>
> We are re-targeting the gcc 4.8.1 to the 16 bit core ,where word =int
> = short = pointer= 16 , char = 8 bit and long =32 bit.
>
> We model the above requirement as
>
> #define BITS_PER_UNIT 8
>
> #define BITS_PER_WOR
On Oct 9, 2013, at 5:24 AM, Umesh Kalappa wrote:
> Dear Group ,
>
> We are re-targeting the GCC to the CISC target ,which has the eight
> 8-bit registers and same register set can used as pair register for
> 16 bit computation i.e four 16-bits .
>
> Any one in the group tell me ,How do i
On Aug 28, 2013, at 8:52 PM, Samuel Mi wrote:
> On Thu, Aug 29, 2013 at 2:54 AM, Jan-Benedict Glaw wrote:
>> On Thu, 2013-08-29 02:43:54 +0800, Samuel Mi wrote:
...or can you, instead of using the Java-based
client part of Jenkins, issue all commands over a SSH (or maybe even
Te
On Jul 10, 2013, at 12:44 PM, Jeff Law wrote:
> On 07/10/2013 10:29 AM, Jonathan Wakely wrote:
>> On 10 July 2013 17:11, Andi Kleen wrote:
>>> FWIW basically -Werror -Wall defines a compiler version specific
>>> variant of C. May be great for individual developers, but it's always
>>> a serious m
On Jul 10, 2013, at 10:42 AM, Andi Kleen wrote:
> Andrew Haley writes:
>
>> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>>> With this situation at hand, I wonder whether it's a good idea to keep
>>> maybe-uninitialized included in -Wall. Projects which have been using
>>> "-Wall -Werror" succ
On Mar 6, 2013, at 7:38 AM, David McQuillan wrote:
> Have there been any implementations of gcc for a 32 bit pointer system where
> the registers are 64 bits long?
MIPS (N32 ABI, and if you want, also O64) is another example.
paul
On Feb 13, 2013, at 5:04 PM, Diego Novillo wrote:
> ...
> Ah, so if we rename a file with 'svn rename', its history will be
> preserved across the rename? In that case, renaming files should not
> be a problem.
Yes, that's one of many ways that SVN (or most other source control systems)
are su
On Nov 26, 2012, at 3:57 PM, Bill Beech (NJ7P) wrote:
> I have run into a problem with both 4.6.1 and 4.7.2 of the gcc compiler
> handling type short. Sizeof(unsigned short) returns a length of 2 as
> expected, but when I use a union of a character buffer and some fields
> including a unsigne
On Sep 7, 2012, at 2:02 PM, Andrew Pinski wrote:
> On Fri, Sep 7, 2012 at 10:57 AM, wrote:
>> This seems to be a bug:
>>
>> struct bug
>> {
>>int f1:1;
>>unsigned long long f2:31;
>> };
>>
>> struct bug test = { 1, 0x8000ULL };
>>
>> int main (int c, char **v)
>> {
>>unsigned lon
This seems to be a bug:
struct bug
{
int f1:1;
unsigned long long f2:31;
};
struct bug test = { 1, 0x8000ULL };
int main (int c, char **v)
{
unsigned long long tf2;
tf2 = test.f2 << 16;
if (tf2 == 0x8000ULL)
return 0;
return 1;
}
Since the underlying typ
On Aug 28, 2012, at 9:45 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 28 Aug 2012, Ian Lance Taylor wrote:
>
>>> Or do we have a rule than any file using C++ specific feature should
>>> be renamed from *.c to *.cc at the moment the C++ feature goes inside?
>>
>> We do not have such a rule and I
On Aug 27, 2012, at 4:05 PM, Gabriel Dos Reis wrote:
> On Mon, Aug 27, 2012 at 1:48 PM, wrote:
>> I'm doing some checking of data structure layouts in different releases of
>> our code -- which were produced by different releases of GCC (3.3.3 vs.
>> 4.5.4).
>>
>> One difference I'm seeing t
On Aug 27, 2012, at 3:33 PM, Jonathan Wakely wrote:
> On 27 August 2012 19:48, Paul_Koningwrote:
>> I'm doing some checking of data structure layouts in different releases of
>> our code -- which were produced by different releases of GCC (3.3.3 vs.
>> 4.5.4).
>>
>> One difference I'm seeing t
I'm doing some checking of data structure layouts in different releases of our
code -- which were produced by different releases of GCC (3.3.3 vs. 4.5.4).
One difference I'm seeing that is puzzling is in the handling of base classes.
Specifically, the case where a base class has padding at the
On Aug 14, 2012, at 4:17 AM, Richard Guenther wrote:
> On Mon, Aug 13, 2012 at 6:25 PM, wrote:
>> Where does one go to report issues with ISL?
>>
>> Since GCC doesn't build without it, I'm trying to install ISL from sources.
>> That doesn't work. It accepts --with-gmp but there is nothing i
On Aug 14, 2012, at 4:17 AM, Richard Guenther wrote:
> On Mon, Aug 13, 2012 at 6:25 PM, wrote:
>> Where does one go to report issues with ISL?
>>
>> Since GCC doesn't build without it, I'm trying to install ISL from sources.
>> That doesn't work. It accepts --with-gmp but there is nothing i
On Aug 13, 2012, at 12:42 PM, H.J. Lu wrote:
> On Mon, Aug 13, 2012 at 9:01 AM, wrote:
>> The installation instructions seem to imply that GCC can be built without
>> having ISL and/or CLOOG installed, and the configure script accepts
>> --without-isl and --without-cloog.
>>
>> But I can't b
Where does one go to report issues with ISL?
Since GCC doesn't build without it, I'm trying to install ISL from sources.
That doesn't work. It accepts --with-gmp but there is nothing in the Makefile
to pay attention to that -- the compiles are done without any switches so it
fails unless gmp.
The installation instructions seem to imply that GCC can be built without
having ISL and/or CLOOG installed, and the configure script accepts
--without-isl and --without-cloog.
But I can't build that. Reading the installation instructions makes me expect
that such a configuration would skip th
I'm not sure what LTO is supposed to do -- the documentation is not exactly
clear. But I assumed it should make things faster and/or smaller.
So I tried using it on an application -- a processor emulator, CPU intensive
code, a lot of 64 bit integer arithmetic.
Using a compile/assembler run on
On May 14, 2012, at 5:47 PM, Joern Rennecke wrote:
> Quoting paul_kon...@dell.com:
>
>> I'm running into an ICE due to what looks like wrong register allocation,
>> and I'm trying to figure out where the problem lies. It shows up with
>> today's GCC (trunk). I haven't yet tried to narrow i
I'm running into an ICE due to what looks like wrong register allocation, and
I'm trying to figure out where the problem lies. It shows up with today's GCC
(trunk). I haven't yet tried to narrow it down to a particular change.
It shows up in the pdp11 target, -O2. Not clear that this is pdp11
On May 9, 2012, at 5:34 AM, Paulo J. Matos wrote:
> On 08/05/12 21:57, Jan Hubicka wrote:
>>
>> In expanded form it is
>>
>> (set (reg5) (const 10))
>>
>> (parallel [(set (reg2) (const 0))
>>(set (reg0) (plus (reg3) (reg5)))
>>(set (reg1) (plus (reg4) (reg5)))
>>
On May 4, 2012, at 1:52 PM, Ian Lance Taylor wrote:
> writes:
>
>> On May 4, 2012, at 11:39 AM, Ian Lance Taylor wrote:
>>
>>> writes:
>>>
I thought that the "operand" in a mem:BLK is the pointer to the block,
not the block itself. So if the instruction(s) generated don't touch
>>
On May 4, 2012, at 11:39 AM, Ian Lance Taylor wrote:
> writes:
>
>> I thought that the "operand" in a mem:BLK is the pointer to the block,
>> not the block itself. So if the instruction(s) generated don't touch
>> the pointer -- a likely answer for a block-move instruction -- then
>> the opera
On May 4, 2012, at 9:44 AM, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>> Expand generates:
>>
>> (define_insn_and_split "movmem_long"
>> [(set (match_operand:QI 2 "register_operand" "d,c") (const_int 0))
>> (set (mem:BLK (match_operand:QI 0 "register_operand" "d,c"))
>>(m
I think this is what secondary reload is for. Check the internals manual.
Something like this shows up in the pdp11 port, where float registers f4 and f5
can't be loaded/stored directly. You can see in that port how this is handled;
it seems to work.
paul
On Apr 27, 2012, at 5:31 PM,
Tested x86_64-apple-darwin10, pdp11-aout -- both pass.
paul
I think removing an existing warning from -Wall would be a bad idea.
paul
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Gerald
Pfeifer
Sent: Monday, April 09, 2012 12:30 PM
To: Robert Dewar
Cc: Jonathan Wakely; James Cloos; gcc@gcc.gnu
I would prefer this to generate a warning. The C language standard change you
refer to is a classic example of a misguided change, and any code whose
behavior depends on this deserves a warning message, NOT an option to work one
way or the other.
paul
-Original Message-
From:
Write a test that checks for the existence of that machinery. I agree with the
earlier comments. Checking version strings or program names is the wrong way,
because you're essentially saying "if it is X then I know it can do Y" rather
than directly asking the question "can it do Y". The issue
...
>> It's never correct to exchange volatile accesses.
>
>That's not true. volatile accesses to different memory locations
>have no special dependence. If it happens that GCC doesn't
>do this kind of things then this is only because most passes
>don't thouch volatile stmts at all (thus the repo
> If I have a structure e.g.
> struct test_s {
> int32_t var1;
> int32_t var2;
> uint64_t var3;
> int var4;
> } test;
>
> If I have an offset value of 8, I wish to do a lookup and get to:
> test.var3
>
> Is there some part of gcc that I could use to parse .h files and
> produce a t
>There are lots of parts of the compiler that don't optimize well when an insn
>has more than one output. For the normal insn, just clobber the flags; don't
>include a second SET.
Yes, but... isn't the whole point of CC modeling that you can take advantage of
the CC left around by an instructi
>From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
>Richard Henderson
>On 10/17/2011 03:50 AM, Paulo J. Matos wrote:
>>...
>> (for example, it would be ok to output negqi2, xorqi3 and
>> addc_internal since xorqi3 only sets N and Z, not the Carry bit)
>
>For that you'd have
>genmodes.c has the following comment:
>
>
> /* Again, nothing more need be said. For historical reasons,
>
>
> the size of a CC mode is four units. */
> validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET);
>
> m->bytesize = 4;
>
>
>Now, this is probably ok f
I think the point is that the effect of -Wmissing-prototypes is always enabled
in C++, so that switch is rejected. The solution would seem to be to remove
that switch from the command line if C++ is used to build; that will produce
the intended result.
paul
-Original Message-
>arc m32c m68hc11 mmix pdp11 score vax
I'll try to get to pdp11 soon.
paul
89 matches
Mail list logo
