On Tue, Mar 25, 2025 at 10:13 PM Martin Uecker wrote:
> Am Dienstag, dem 25.03.2025 um 19:09 -0700 schrieb Bill Wendling:
> > On Tue, Mar 18, 2025 at 3:04 PM Martin Uecker wrote:
> > >
>
> >
> > It seems clear that using "__self" is most likely goin
On Tue, Mar 18, 2025 at 3:04 PM Martin Uecker wrote:
>
> Am Dienstag, dem 18.03.2025 um 14:03 -0700 schrieb Yeoul Na via Gcc:
> >
> > > On Mar 18, 2025, at 12:48 PM, Martin Uecker wrote:
> > >
> > > Am Dienstag, dem 18.03.2025 um 09:52 -0700 schrieb Yeoul Na via Gcc:
> > > >
> > > > > On Mar 18,
On Dec 16, 2009, at 1:26 AM, Paolo Bonzini wrote:
> On 12/16/2009 03:21 AM, John Regehr wrote:
>> Hopefully the results are more fair and useful now. Again, feedback is
>> appreciated.
>
> I would also avoid testcases using volatile. Smaller code on these
> testcases is often a sign of miscomp
On Mon, Apr 20, 2009 at 1:34 PM, Kirill Kononenko
wrote:
> Hello
>
>
> So how did it happen that the only project which was a candidate for
> libJIT Summer of Code in GNU, with the same title got selected in
> LLVM?
>
>
> Does it mean that the same genius idea came to two minds?
>
No. It's a consp
On Jun 15, 2007, at 3:45 PM, Mark Mitchell wrote:
Bill Wendling wrote:
Perhaps I'm mistaken, but the above seems to indicate to me that the
structure (and, therefore, all of its fields) are hidden, one of its
functions is from an external and visible source.
Yes. And, therefore, emitt
On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote:
Consider:
struct __attribute__((vsibility ("hidden"))) S {
void __declspec(dllimport) f();
};
At present, we give "f" hidden visibility. That seems odd since the
user has explicitly told us that the symbol is coming from another
shared l
I'm sure there are some at your school's website. Or you can ask you
TA for help with your homework.
-bw
On May 15, 2007, at 11:33 AM, craig clow wrote:
Hello,
Does anyone know of a good web site for sample C code supported by
GCC 3.3.2?
Specifically, I am looking for code that can read f
On May 12, 2007, at 6:32 AM, Andrew Pinski wrote:
On 5/11/07, Bill Wendling <[EMAIL PROTECTED]> wrote:
This one was just filed against 4.2.0:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
It is causing LLVM (at least) to fail to build. Do you think it's
worth adding
On May 11, 2007, at 5:15 PM, Mark Mitchell wrote:
Bill Wendling wrote:
This one was just filed against 4.2.0:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
It is causing LLVM (at least) to fail to build. Do you think it's
worth
adding to the list?
Does it show up anywhere
On May 11, 2007, at 3:02 PM, Mark Mitchell wrote:
Every time I think we're almost there with this release, I seem to
manage to get stuck. :-( However, we're very close: the only PRs that
I'm waiting for are:
PR 30252: Wrong code generation, perhaps due to the C++ front end's
representation for
On Apr 8, 2007, at 11:35 PM, Dave Korn wrote:
I believe I got the TOT -- .svn/entries says "svn://gcc.gnu.org/svn/
gcc/trunk". Is this a known problem?
It's the first I've heard of it, please file a PR. I'm slightly
amazed this
hasn't been causing bootstrap breakage already, it looks real
On Apr 8, 2007, at 6:50 PM, Bill Wendling wrote:
Hi all,
This program:
#include
struct tree_type {
unsigned int precision : 9;
};
void *bork(const void *Ty, unsigned Subpart) {
printf("Subpart == %08x\n", Subpart);
return 0;
}
const void *TConvertType(tree_type* type) {
Hi all,
This program:
#include
struct tree_type {
unsigned int precision : 9;
};
void *bork(const void *Ty, unsigned Subpart) {
printf("Subpart == %08x\n", Subpart);
return 0;
}
const void *TConvertType(tree_type* type) {
asm("movl $1104150528, (%%esp)" : : );
const void *Ty = 0;
On Nov 10, 2006, at 9:08 PM, Geert Bosch wrote:
Most people aren't waiting for compilation of single files.
If they do, it is because a single compilation unit requires
parsing/compilation of too many unchanging files, in which case
the primary concern is avoiding redoing useless compilation.
T
14 matches
Mail list logo
