On Jun 22, 2020, at 3:51 PM, Eric Gallager wrote:
>
> Hi, at Apple's WWDC this year they have announced that they are doing
> yet another architecture transition, so I was wondering what exactly
> would be the best way to go about adding support for it?
I usually use emacs and git to add ports t
On May 14, 2020, at 11:11 AM, Tom Tromey wrote:
>
>> "Rob" == Rob Savoye writes:
>
> Rob> Not that team, the folks I talked to thought I was crazy for wanting
> Rob> to refactor it. :-)
>
> I don't think refactoring dejagnu is crazy, but I think it's pretty hard
> to imagine rewriting th
As seen in recent bug report:
CVS Commits 2020-05-12 20:40:40 UTC
I guess that git thing was a bust and we're back to using cvs now. At least
Ian did up the remote patches to make cvs work better.
I've changed the subject to match the 2015, 2017 and 2018 email threads.
On May 13, 2020, at 3:26 AM, Thomas Schwinge wrote:
>
> Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> vs. "new") that ought to return identical results, I found that they
> didn't:
> I have not
On Oct 28, 2019, at 12:40 PM, Jeff Law wrote:
> I'd really like to see us move to C++11 or beyond. Sadly, I don't think
> we have any good mechanism for making this kind of technical decision
> when there isn't consensus.
I'll just point out that we do have good mechanisms in place. Consensus
On Aug 4, 2018, at 9:32 AM, Bernhard Reutner-Fischer
wrote:
> On Tue, 16 May 2017 at 21:08, Mike Stump wrote:
>>
>> On May 16, 2017, at 5:16 AM, Jonathan Wakely wrote:
>>> The change I care about in 1.5.3
>>
>> So, we haven't talked much about the ve
On Nov 14, 2017, at 3:21 PM, Joseph Myers wrote:
>
> On Tue, 14 Nov 2017, Mike Stump wrote:
>> The testsuite/gcc.c-torture/execute/pr34971.c seems wrong to me. The
>> type of the expression x.b << 8 has size 8, a size 8 integral type is a
>> 64-bit type. If the
The testsuite/gcc.c-torture/execute/pr34971.c seems wrong to me. The type of
the expression x.b << 8 has size 8, a size 8 integral type is a 64-bit type.
If the result is a 64-bit type, then it's argument (x.b) was a 64-bit type. In
C++, we observed what they meant in the C language standard
On Aug 2, 2017, at 10:34 PM, Daniel Santos wrote:
>
> I'm working on a patch to modify the testsuite to obey the
> --load-average value if one is passed to make.
The code seems like a reasonable approach. Love to see numbers and test
scenarios so that others can tell if you've covered their us
On May 16, 2017, at 5:16 AM, Jonathan Wakely wrote:
> The change I care about in 1.5.3
So, we haven't talked much about the version people want most. If we update,
might as well get something that more people care about. 1.5.3 is in ubuntu
LTS 16.04 and Fedora 24, so it's been around awhile.
On May 15, 2017, at 1:06 AM, Richard Biener wrote:
>
> Both SLE-11 and SLE-12 use dejagnu 1.4.4, so does openSUSE Leap 42.[12].
> Tumbleweed uses 1.6 so new SLE will inherit that. But I still do all
> of my testing on systems with just dejagnu 1.4.4.
So dejagnu is independent of most things and
> On Apr 10, 2017, at 8:17 AM, David Edelsohn wrote:
>
> On Mon, Apr 10, 2017 at 10:58 AM, Simon Wright wrote:
>> I see that, in the GCC 7 Release Criteria, the Secondary Platforms list
>> includes i686-apple-darwin.
>>
>> Should this now be x86_64-apple-darwin? I've been building this since
On Jan 11, 2017, at 3:29 PM, Daniel Santos wrote:
> On 01/11/2017 12:25 PM, Joseph Myers wrote:
> Would this then be the correct test?
Yeah, looks good.
On Jan 10, 2017, at 9:13 PM, Daniel Santos wrote:
> I've gotten rid of the Makefile and everything is run now from msabi.exp.
> I've also gotten rid of the header file, now that I know how to define a
> "_noinfo" fn pointer, so it's down to just 4 files: msabi.exp, gen.cc,
> msabi.c and do_tes
On Dec 31, 2016, at 2:13 PM, Daniel Santos wrote:
>
> Well I'm learning all sorts of new things; I wasn't aware that the testsuite
> was designed to run with other compilers! Does the Microsoft compiler
> support building functions using the System V ABI?
IDK. I kinda doubt it.
On Dec 31, 2016, at 11:18 AM, Daniel Santos wrote:
>
> The generated sources are 2MiB
Yeah, too big, better to have a generator.
> Also, I can't have the two generated .c files in the same translation unit
> (at least in their current form) because gcc's too smart with optimizations.
> :)
Yo
On Dec 30, 2016, at 11:58 AM, Daniel Santos wrote:
>
> Still being pretty new to GCC and having never used dejagnu, expect or Tcl,
> I'm trying to determine how to best integrate my test program into GCC's test
> harness. I wrote this to help find breakages while working on optimizations
> fo
On Sep 8, 2016, at 1:53 AM, Uros Bizjak wrote:
>
> On Mon, Sep 5, 2016 at 1:45 PM, Joseph Myers wrote:
>> On Sun, 4 Sep 2016, Uros Bizjak wrote:
>>
>>> It looks that different handling of _Complex char, _Complex short and
>>> _Complex float is there on purpose. Is (was?) there a limitation in a
On Jul 25, 2016, at 9:37 AM, Joseph Myers wrote:
>
> On Fri, 15 Jul 2016, Thomas Schwinge wrote:
>
>>> No, we want to have as little churn as possible in existing tests, the
>>> general policy is to add new tests (not just for OpenACC/OpenMP, but for
>>> all functionality).
>>
>> Hmm, that's so
On Sep 16, 2015, at 12:02 PM, Bernhard Reutner-Fischer
wrote:
> Where Joseph said he'd wait some more.. I had thought I asked longer ago than
> that, time flies if one has fun.
>
> I'd just require 1.5.3 just to avoid the time needed by folks to workaround
> those silly ordering gotchas and lo
On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan
wrote:
>
> Sorry about the obvious (possibly dumb) question.
> Can't we just import a copy of dejagnu each year and install it as part of
> the source tree?
TL;DR: No.
We could, and indeed, some people do engineering that way. We instead dep
On Sep 16, 2015, at 12:29 AM, Andreas Schwab wrote:
> Mike Stump writes:
>
>> The software presently works with 1.4.4 and there aren’t any changes
>> that require anything newer.
>
> SLES 12 has 1.4.4.
Would be nice to cover them as well, but their update schedule
On Sep 15, 2015, at 1:04 PM, Jeff Law wrote:
> Given we haven't updated the dejagnu reqs since ~2001, I think stepping
> forward would be appropriate and I'd support moving all the way to 1.5.3 with
> the expectation that we'll be on a cadence of no faster than 2 years going
> forward.
So, I a
On Sep 14, 2015, at 3:37 PM, Jeff Law wrote:
>> Maybe GCC-6 can bump the required
>> dejagnu version to allow for getting rid of all these superfluous
>> load_gcc_lib? *blink* :)
> I'd support that as a direction.
>
> Certainly dropping the 2001 version from our website in favor of 1.5 (which
>
On Dec 17, 2014, at 3:44 AM, Jakub Jelinek wrote:
> On Wed, Dec 17, 2014 at 11:16:18AM +0100, Dominique Dhumieres wrote:
>> Currently gcc 4.8.4 does not bootstrap on darwin14 (Yosemite) due to pr61407.
>
> Why has it not been pushed in earlier?
No good reason. No one checked it into the release
On Dec 17, 2014, at 2:21 AM, FX wrote:
>> Currently gcc 4.8.4 does not bootstrap on darwin14 (Yosemite) due to pr61407.
>> Would it be possible to apply the patch at
>> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33932
>> before 4.8.4 is released? Results with the patch are posted at
>> https:
On Dec 16, 2014, at 1:24 PM, Dominique d'Humières wrote:
> My patch is different and I am attaching it (it is quite old, so it may not
> apply cleanly). The problem for more evolved form is that *.dSYM are
> directories and ASAICT there is no command in derange to remove them.
>
> At least my p
On Dec 16, 2014, at 12:46 PM, Iain Sandoe wrote:
>
> On 16 Dec 2014, at 20:40, Dominique d'Humières wrote:
>>
>>> Another testsuite issue on darwin is that testsuite doesn’t clean up the
>>> .dSYM directories it generates. This gets really annoying on my autotester
>>> :(
>>
>> I have a patch
On Nov 25, 2014, at 12:15 PM, Jakub Jelinek wrote:
> On Tue, Nov 25, 2014 at 03:27:40PM +0100, Tom de Vries wrote:
>> This patch fixes that by ensuring that we print that unsupported message
>> only once.
>>
>> The resulting test result comparison diff is:
>> 2014-11-25 Tom de Vries
>>
>>
On Nov 23, 2014, at 4:06 PM, FX wrote:
> One question to build maintainers, and one patch submitted to top-level
> configure.ac
So, not sure who wants to review this. From the darwin perspective, Ok.
On Oct 7, 2014, at 2:07 PM, Marek Polacek wrote:
> I'd like to kick off a discussion about moving the default standard
> for C from gnu89 to gnu11.
I endorse the change of default.
> The things I had to fix in the testsuite nicely reflect what we can expect
> in the real life:
A wiki page that
On Sep 15, 2014, at 9:05 AM, Jakub Jelinek wrote:
All the updates sound good.
> Regtested on x86_64-linux, without the patch toplevel make -k check
> took 8hrs3minutes (don't have time data for that run),
This confuses me, but, no matter. Isn’t 8hrs time data? :-)
> patch toplevel make -j48
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> Here is my latest version of the patch.
I did a timing test:
Before:
real0m57.198s
user1m24.736s
sys 0m19.816s
after:
real0m28.224s
user1m27.823s
sys 0m22.374s
This is a -j70 run on a 64 core power7 of check-objc, I
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> Here is my latest version of the patch.
>
> With this patch I get identical test_summary output on make -k check
> (completely serial testing) and make -j48 -k check from toplevel directory.
>
> Major changes since last version:
> 1) I've chang
On Sep 11, 2014, at 3:15 PM, Jakub Jelinek wrote:
> That is news to me, but given the amount of test -a/-o uses e.g. in
> gcc/configure and hundreds of places, I'd say what we care is what is more
> portable to old shells.
No, we can’t care about that. If that were true, the _ && _ in the compil
On Sep 10, 2014, at 2:23 PM, Jakub Jelinek wrote:
> Seems file mkdir in tcl doesn't error on pre-existing directory,
shell mkdir will. :-)
On Sep 10, 2014, at 1:38 PM, David Malcolm wrote:
> Perhaps this is a silly question, but has anyone tried going the whole
> way and not having buckets, going to an extremely fine-grained approach
No, we fear the overhead, but do not know what it is.
On Sep 9, 2014, at 8:14 AM, VandeVondele Joost
wrote:
> Attached is a further revision of the patch, now dealing with check-c++.
So when last I played in this area, I wanted a command line tool that would
bin-pack from the command line. I would then grab the seconds per for each
.exp, and bin
On Sep 5, 2014, at 4:05 AM, Thomas Schwinge wrote:
> Updating my GCC trunk working tree from r212389 (2014-07-09) to r214918
> (2014-09-04), I notice that (only) in libstdc++ testing, and only for the
> second multilib of »RUNTESTFLAGS='--target_board=unix\{,-m32\}'« (so, the
> 32-bit x86 one), a
Gosh, https://gcc.gnu.org/projects/cxx0x.html and
https://gcc.gnu.org/gcc-4.8/cxx0x_status.html seem to old and dated now.
First, the standard before last has been published. Second, at some point, it
can’t be experimental anymore. Would be nice if someone could update the
content. The part
Ping?
Or, I can ask, any objections? In https://gcc.gnu.org/PR61146 it is stated
that GMP removed the casts in 2005.
On May 26, 2014, at 4:26 AM, FX wrote:
>> So changing just 2 of them doesn't feel right to me…
>
> [Again, with the patch actually attached… sorry]
>
> Here’s a patch that rem
On May 26, 2014, at 2:22 AM, FX wrote:
>> This causes GCC bootstrap to fail on Darwin systems (whose system compiler
>> is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure
>> it’s the right call, see below), I’ve filed a separate report for the
>> bootstrap issue (https://
On May 26, 2014, at 4:26 AM, FX wrote:
> Here’s a patch that removes all the casts on output operands in x86/x86_64
> code in longlong.h.
I’d love for someone to explain why the casts were there in the first place… I
like the idea of removing them.
So, I was wondering about patterns like:
(define_insn_and_split "*setcc_di_1"
[(set (match_operand:DI 0 "register_operand" "=q")
(match_operator:DI 1 "ix86_comparison_operator"
[(reg FLAGS_REG) (const_int 0)]))]
"TARGET_64BIT && !TARGET_PARTIAL_REG_STALL"
"#"
"&& reload_c
On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote:
> please hold off on committing patches for the next couple of hours as we have
> a very large merge to do.
> thanks.
All done… It is in.
On Feb 13, 2014, at 1:18 AM, Richard Sandiford
wrote:
> This patch tries to reduce that by providing an alternative single-script
> version.
> Python isn't yet required and I'm pretty sure this script needs 2.6
> or later.
> I'm also worried that the seek/tell stuff might not work on
> Windows.
I am seeing the below on wide-int. The go teststsuite violates one of the
principals of goo test suite hygiene, the names thought arbitrary, should be
stable. These names are not stable across differing build locations.
s,.*/testsuite/,,g is approximately what it needs. Thanks.
New tests t
On Apr 22, 2014, at 12:48 PM, Kenneth Zadeck wrote:
>
>>> While of course one hopes that there will be no issues with wide-int, a
>>> change of this size will have some pain no matter how well we have
>>> tested it. Having three reviewers will assure problems are resolved
>>> quickly.
>> Works f
Since we are nearing release, I thought I’d mention I see:
../../gcc/gcc/doc/invoke.texi:1114: warning: node next `Overall Options' in
menu `C Dialect Options' and in sectioning `Invoking G++' differ
../../gcc/gcc/doc/invoke.texi:1114: warning: node up `Overall Options' in menu
`Option Summary'
I've been doing make -j70 and -j70 restrap and libasan seems to build 1 file at
a time. I'm chasing other bits right now, so I didn't track down what did it.
I looked at how it is wired up and didn't just spot it, and it seems to copy
other runtime libraries we have. Not sure if they suffer t
On Nov 22, 2013, at 10:13 AM, Jakub Jelinek wrote:
>> This is exactly the patch referenced in the pointer to the upstream repo.
>> Arno, does this fix the build for you?
>>
>> Ok?
>
> Yes
Committed revision 205285.
On Nov 22, 2013, at 4:31 AM, Konstantin Serebryany
wrote:
> These CFI directives were completely removed in upstream at
> http://llvm.org/viewvc/llvm-project?rev=192196&view=rev
> Strangely, this did not get into the last merge...
>
> Anyway, these cfi_* will (should, at least) disappear with th
On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov wrote:
> Mike, as Obj-C/C++ front-end maintainers, would you be supportive of Blocks
> extension implemented for Obj-C/C++ front-ends?
Sure.
Though, I'd really love a front-end extension to allow one to implement Blocks
as a pure library. :-) [ duck
On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov wrote:
> I am considering a project to add Apple's blocks [*] extension to GCC.
I have a funny story about that one… I was just about ready to submit the
work, the GPLv3 happened. Ah… life goes on.
On Nov 3, 2013, at 8:49 PM, pins...@gmail.com wrote:
> What benefits does blocks have over nested functions in C and over lambas in
> C++?
The ability to compile existing code. The ability to compile code that uses
system header files on macosx. The ability to use third party libraries on
mac
On Oct 15, 2013, at 5:41 AM, Richard Biener wrote:
> That said, how do cc1 binary sizes compare branch vs. trunk at
> the last merge point?
$ size /tmp/gcc-*/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus
textdata bss dec hex filename
14224227 33960 1061304 153194
So, here is a comparison of the time required to do a make -j15 of a
--disable-bootstrap --enable-checking=none --enable-languages=c,c++ style
compiler. The base compiler is a --enable-checking=none
--enable-languages=c,c++,lto style compiler, which is
1b2bf75690af8115739ebba710a44d05388c7a1a
On Aug 28, 2013, at 2:40 AM, Richard Biener wrote:
> Digging shows I at one point removed all this code - but people objected and I
> had to revert it :/
[ oh,, sorry to hear ] I got rid of it as well, and then the test suite beat
on me til I relented.
> I suppose this kind of cleanup should b
On Aug 27, 2013, at 3:23 AM, Richard Biener wrote:
>> +++ b/gcc/fold-const.c
>> @@ -3702,12 +3702,23 @@ all_ones_mask_p (const_tree mask, int size)
> This should instead use
>
> return tree_to_double_int (mask) == double_int::mask (size)
> || (TYPE_PRECISION (mask) == size && tree_to_doubl
It is the intent for all_ones_mask_p to return true when 64 bits of ones in an
unsigned type of width 64 when size is 64, right? Currently the code uses a
signed type for tmask, which sets the upper bits to 1, when the value includes
the sign bit set and the equality code does check all 128 bit
A make clean followed by a make in the libgcc directory results in:
../../../../gcc/libgcc/config/i386/cpuinfo.c:23:25: fatal error: auto-target.h:
No such file or directory
#include "auto-target.h"
Oh, the the old days, we'd just add a dependancy… If someone knows where to add
just the right
On Apr 25, 2013, at 7:44 AM, Senthil Kumar Selvaraj
wrote:
> What is right way to fix these? I saw one testcase that did
>
> typedef int int32_t __attribute__ ((__mode__ (__SI__)));
>
> Is this the right way to go?
I like this. Pre-approved.
On Apr 1, 2013, at 6:43 PM, Jason Merrill wrote:
> On 03/30/2013 02:23 AM, Senthil Kumar Selvaraj wrote:
>> I couldn't find a way to ask gcc to just generate DWARF (default
>> version) either. How should this be fixed?
>
> Maybe we could use -gdwarf for that now, since we stopped using it for DWA
On Mar 28, 2013, at 3:57 AM, Senthil Kumar Selvaraj
wrote:
> On Wed, Mar 27, 2013 at 08:43:53AM -0700, Mike Stump wrote:
>> On Mar 27, 2013, at 1:02 AM, Senthil Kumar Selvaraj
>> wrote:
>>> global-used-types.c in gcc/testsuite/gcc.dg/debug/dwarf2 only specifies
>
On Mar 27, 2013, at 1:02 AM, Senthil Kumar Selvaraj
wrote:
> global-used-types.c in gcc/testsuite/gcc.dg/debug/dwarf2 only specifies
> -g in dg-options. For a target that is not configured to generate
> dwarf-2 by default, the test fails looking for specific DWARF strings in
> the generated assem
Someone removed isl-0.10.tar.bz2 and cloog-0.17.0.tar.gz from
ftp://gcc.gnu.org/pub/gcc/infrastructure. I'd hoping this was in error and the
files can be restored. If there is some compelling reason, I am interested.
On Nov 27, 2012, at 4:50 PM, "Joseph S. Myers" wrote:
> On Tue, 27 Nov 2012, Mike Stump wrote:
>
>> A review of the change and approval of the change should be enough to
>> catch issues going into the FSF tree. The build should just copy the
>> generated f
On Nov 27, 2012, at 1:22 PM, Andrew Pinski wrote:
> On Tue, Nov 27, 2012 at 12:55 PM, Mike Stump wrote:
>> This:
>>
>> Verify that you have permission to grant a GFDL license for all
>> new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi.
>> make[3]:
This:
Verify that you have permission to grant a GFDL license for all
new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi.
make[3]: *** [s-tm-texi] Error 1
make[3]: *** Waiting for unfinished jobs….
is one of the stupidest build errors I've seen all decade. Can someone fix it
please?
On Sep 6, 2012, at 1:00 PM, Ian Lance Taylor wrote:
> On Thu, Sep 6, 2012 at 11:56 AM, Mike Stump wrote:
>> Where in the manual are the machine specific print operand modifiers
>> documented? I've looked around, and just can seem to find them; surely, I
>> can'
On Sep 6, 2012, at 1:09 PM, David Daney wrote:
> On 09/06/2012 01:00 PM, Ian Lance Taylor wrote:
>> On Thu, Sep 6, 2012 at 11:56 AM, Mike Stump wrote:
>>> Where in the manual are the machine specific print operand modifiers
>>> documented? I've looked around
Where in the manual are the machine specific print operand modifiers
documented? I've looked around, and just can seem to find them; surely, I
can't be the first to document such a modifier.
In doing up the mods for the constant wide int code, we found a nasty including
ordering problem that seems only tangentially related to our code. In
options.h this is generated:
/* Anything that includes tm.h, does not necessarily need this. */
#if !defined(GCC_TM_H)
#include "input.h" /* for
On Jul 2, 2012, at 4:06 AM, Alexandre Oliva wrote:
> On Jun 29, 2012, Mike Stump wrote:
>> First, let get to the heart of the matter. That is the behavior of
>> compiler.
>
> That's a distraction in the context of a patch to improve a feature
> that's already
On Jun 28, 2012, at 3:19 PM, Alexandre Oliva wrote:
> On Jun 28, 2012, Mike Stump wrote:
>> The next would be because it would be a speed hit to re-check at
>> runtime the qualities of the linker and do something different.
>
> But then, our testsuite *does* re-check at ru
On Jun 28, 2012, at 4:39 AM, Alexandre Oliva wrote:
> On Jun 28, 2012, Jakub Jelinek wrote:
>
>> On Thu, Jun 28, 2012 at 04:16:55AM -0300, Alexandre Oliva wrote:
>>> I'd very be surprised if I asked for an i686 native build to package and
>>> install elsewhere, and didn't get a plugin just becau
On Jun 28, 2012, at 12:16 AM, Alexandre Oliva wrote:
> On Jun 27, 2012, Mike Stump wrote:
>> On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
>>> Why? We don't demand a working plugin. Indeed, we disable the use of
>>> the plugin if we find a linker that do
On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
> Why? We don't demand a working plugin. Indeed, we disable the use of
> the plugin if we find a linker that doesn't support it. We just don't
> account for the possibility of finding a linker that supports plugins,
> but that doesn't support t
On Jun 25, 2012, at 6:48 AM, Steven Bosscher wrote:
> In fact darwin does follow the
> naming convention, the only difference is that it wraps the section
> name in a segment label (always "__DWARF__") and adds some flags
> (always "regular,debug"). I would have expected there to be a way to
> chan
On Jun 5, 2012, at 1:23 PM, Steven Bosscher wrote:
> On Tue, Jun 5, 2012 at 8:55 PM, Iain Sandoe wrote:
>> I would welcome a simple solution if one is available, although I don't
>> quite see what you have in mind at present.
>
> This is what I have in mind. Untested, but it shows the idea. What
On Mar 26, 2012, at 1:56 PM, Steven Bosscher wrote:
> This patch is one way to address PR44982.
That's a great idea, I like it. There is only one problem that I know of that
prevents it from going in now. We emit errors/warnings from below finalize and
there is a feature in which we emit all t
On Aug 15, 2011, at 5:42 AM, Richard Guenther wrote:
> The argument still holds that no reasonable memcpy implementation
> will reject the src == dest case.
Hum... Sounds like if that's the case that we should document it in the manual
as something we expect (requirement) of the memcpy implement
On Jul 20, 2011, at 1:25 PM, Ian Lance Taylor wrote:
> Interesting. I don't know why this doesn't happen on GNU/Linux.
It doesn't happen as the symbols in question are local on linux. collect2 runs
nm on public symbols looking for symbols of a particular form, it then builds
two lists, one for
On Jun 12, 2011, at 4:03 AM, Richard Guenther wrote:
> Btw, see tree.def which says
>
> /* Represents viewing something of one type as being of a second type.
> This corresponds to an "Unchecked Conversion" in Ada and roughly to
> the idiom *(type2 *)&X in C. The only operand is the value to
So, I have a machine that has many styles of branches, among them, a normal
one, and a short version. The short version is cheaper (sometimes). The
regular one is 1 (predicted), 7 mis-predicted. The cost of mis-prediction can
be substantially higher depending upon what is in the cache. The s
So, I was trying to debug some stuff with the top of the tree on a suse linux
x86_64 box and got:
(gdb) p mode
Unhandled dwarf expression opcode 0xf3
which I don't find entertaining. I know I _could_ install a new gdb, and most
likely this would fix the problem, but, I don't want to do that ri
On Feb 17, 2011, at 4:09 PM, Nicola Pero wrote:
> This patch is not me - it's by Iain Sandoe. :-)
Thanks for chipping in and helping out. I'm excited at having a Objective-C
compiler that works again on darwin.
That said, if people have any Objective-C codes, feel free to beat on them and
let
On Feb 15, 2011, at 2:47 PM, Gerald Pfeifer wrote:
> I am happy to announce that the steering committee has appointed
> Rainer Orth and Mike Stump testsuite maintainers.
Since I'm sure I can't figure out which patches are outstanding, could anyone
waiting on testsuite approval
On Feb 7, 2011, at 2:51 AM, Richard Guenther wrote:
> I would say add a new hook that can be called from build_common_builtin_nodes
> instead.
Ok, thanks.
So, in c-common.c we have:
targetm.init_builtins ();
build_common_builtin_nodes ();
and in f95-1.c we have:
build_common_builtin_nodes ();
targetm.init_builtins ();
I would like to change c-common.c to match fortran, so that the target hook can
slightly alter (rename) the linkage name
On Dec 31, 2010, at 8:27 AM, Gerald Pfeifer wrote:
> On Wed, 8 Dec 2010, DJ Delorie wrote:
>> http://gcc.gnu.org/rsync.html says 17 Gb.
>>
>> I just did it, and it's up to 22 Gb.
>
> Thanks for the heads up, DJ! I had a look, and it is, in fact,
> 184 Gb as of today, or 23 GB. (SCNR. :-)
You c
On Sep 15, 2010, at 2:17 PM, Richard Kenner wrote:
> FSF *policy* (not the GPL) requires that all files have "GPLv3-or-later"
> license. The question is what permission you need to change a file
> that has a "GPLv2-or-later" license into the required one.
None, the GPL v2 clause grants this right
On Sep 10, 2010, at 7:51 PM, Richard Kenner wrote:
> I disagree. The copyright holder has decided that they want people to
> (among other things) allow people to distribute under GPLv2. We can't
> take that away without the permission of that holder.
Well, the words on their distribution say exa
On Sep 10, 2010, at 11:06 AM, Richard Kenner wrote:
> The fact that the licenses are COMPATIBLE doesn't make them IDENTICAL.
> FSF wants "GPLv3 or later" and it's not at all clear to me that we could
> change the license of code that's not copyright assigned to FSF to that
> license (we can for cod
On Sep 10, 2010, at 2:42 AM, Richard Guenther wrote:
> On Fri, Sep 10, 2010 at 11:38 AM, Steven Bosscher
> wrote:
>> Not that I want to discourage anyone. Just practical considerations...
>> ;-) I can't believe I'm saing this but: It may be better to spend
>> some effort on making clang work as
On Sep 10, 2010, at 5:40 AM, Richard Kenner wrote:
> More seriously, the issue is copyright law. In order to write a
> front-end for GCC right now (or for a GCC front end to use another
> backend), you have to use a sufficient number of header files and
> interfaces of GCC that there's no question
On Sep 10, 2010, at 4:52 AM, Richard Kenner wrote:
> I thought the point is that Apple WON'T go to GPLv3.
The Apple distributions are GPLv2 or later, meaning if someone wanted to take
that code and distribute it under then GPLv3, they could.
On Sep 9, 2010, at 3:11 AM, Nicola Pero wrote:
> Can we (legally) merge Apple's Objective-C / Objective-C++ modifications to
> GCC into FSF GCC trunk ?
My take, you'd have to ask either the FSF lawyers or Apple, I'm neither. Chris
Lattner could provide an Apple answer, I'd recommend contacting
On Jul 1, 2010, at 11:29 PM, Eric Siroker wrote:
> I'm getting the frontend for the Go programming language to work in
> Darwin. I encountered what looks like a bug in Darwin-specific gcc
> code.
You are obligated to spell the name of the section correctly...
$ cat t.s
.section __TEXT,__
On Jan 21, 2009, at 3:43 PM, Jack Howarth wrote:
So that invalidates your previously proposed patch? Or should I
still test it?
No need to test, I was wrong about that being the bit that causes it.
The description I last posted should be about right however, one just
needs a bit of time i
1 - 100 of 928 matches
Mail list logo
