Can I provide information for the list.
Regards,
Erin Lewis
From: Erin Lewis
Sent: Friday, March 14, 2025 7:36 AM
To: gcc@gcc.gnu.org
Subject: Discover the Latest Trends at Bio-IT World Expo 2025
Just a quick question: would you be interested in receiving the Bio-IT World
Conference &
Just a quick question: would you be interested in receiving the Bio-IT World
Conference & Expo 2025 attendance details?
Attendees: Executive, Director, Manager, Professor, Scientist/Tecnologist,
Sales & Marketing, Assistant and many.
Regards,
Erin Lewis
Last Changed Date: 2014-09-13 12:00:28 -0700 (Sat, 13 Sep 2014)
- Original Message -
From: Jonathan Wakely
To: George R Goffe
Cc: "gcc@gcc.gnu.org"
Sent: Wednesday, September 24, 2014 4:36 PM
Subject: Re: Problems building the latest gcc
On 24 September 2014 22:49, Geor
On 24 September 2014 22:49, George R Goffe wrote:
> Hi,
>
> I'm having trouble building the latest gcc on my fedora 19 x86_64 system.
This mailing list is for discussing development of gcc itself, please
use the gcc-help list for help building or using gcc.
Please send your
Hi,
I'm having trouble building the latest gcc on my fedora 19 x86_64 system. It's
probably something I'm doing wrong but I can't seem to find what. Maybe it is a
bug? Could I get someone to look at the problem please? I have a complete build
log if that's necessary
On Mon, Oct 12, 2009 at 08:09:48AM -0700, Bingfeng Mei wrote:
> Richard,
> Doesn't REGISTER_TARGET_PRAGMAS need to call c_register_pragma, etc, if we
> want to specify target-specific pragma? It becomes part of libbackend.a,
> which is linked to lto1. One solution I see is to put them into a separ
On 10/12/2009 08:09 AM, Bingfeng Mei wrote:
Richard,
Doesn't REGISTER_TARGET_PRAGMAS need to call c_register_pragma, etc, if we
want to specify target-specific pragma? It becomes part of libbackend.a,
which is linked to lto1. One solution I see is to put them into a separate
file so the linker wo
when they are not
actually used by lto1.
Thanks,
Bingfeng
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 12 October 2009 15:34
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: Issues of the latest trunk with LTO merges
&g
On Mon, Oct 12, 2009 at 4:31 PM, Bingfeng Mei wrote:
> Hello,
> I ran into an issue with the LTO merges when updating to current trunk.
> The problem is that my target calls a few functions/uses some data structures
> in the gcc directory: c_language, paragma_lex, c_register_pragma, etc.
>
> gcc -
Hello,
I ran into an issue with the LTO merges when updating to current trunk.
The problem is that my target calls a few functions/uses some data structures
in the gcc directory: c_language, paragma_lex, c_register_pragma, etc.
gcc -m32 -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-s
As we record our next Album, go to
http://www.splitbelly.com
Grab our previous full length Album.. Absolutly FREE!
Nothing to fill out, no strings attached!
We also have a myspace page http://www.myspace.com/splitbelly
You may have seen our site was down for a few days as we hooked up with a n
As we record our next Album, go to
http://www.splitbelly.com
Grab our previous full length Album.. Absolutly FREE!
Nothing to fill out, no strings attached!
We also have a myspace page http://www.myspace.com/splitbelly
You may have seen our site was down for a few days as we hooked up with a n
Paolo Carlini wrote:
Mark Mitchell wrote:
OK, please go ahead and apply the relevant patch -- once we are out of
the slush.
Thanks a lot Mark. To be sure: in my understanding, only mainline is in
slush, not 4_0-branch, where we want to backport the patches. If I'm
mistaken please let us know ASAP
Mark Mitchell wrote:
> OK, please go ahead and apply the relevant patch -- once we are out of
> the slush.
Thanks a lot Mark. To be sure: in my understanding, only mainline is in
slush, not 4_0-branch, where we want to backport the patches. If I'm
mistaken please let us know ASAP.
Paolo.
Kriang Lerdsuwanakij wrote:
Mark Mitchell wrote:
OK. Do you happen to have access to any other testsuites, beyond the
GCC testsuite? If so, it would be great to validate the behavior of
the compiler on the 4.0 branch with and without your patch to make
sure that we're not doing any harm.
I a
Mark Mitchell wrote:
OK. Do you happen to have access to any other testsuites, beyond the
GCC testsuite? If so, it would be great to validate the behavior of
the compiler on the 4.0 branch with and without your patch to make
sure that we're not doing any harm.
I am sorry I don't have it.
--Kr
Kriang Lerdsuwanakij wrote:
I see that either the patch (actually only one of the two fixes this issue:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01283.html ) applied or
leave the current behavior as is. It would do more harm than good
if we try to do something different.
OK. Do you happen to
Mark Mitchell wrote:
Those are somewhat above my pain threshold. Is there something else
that we could do for the 4.0 branch? Like issue a warning and ignore
the friend declaration?
Sorry for long delay. I just got back from a trip (but I will be away
next week as well.) Doing what you sugg
Hi,
On Mon, 2 May 2005, Mark Mitchell wrote:
> At the same time, if the code in question doesn't mean what the person
> who wrote it wants it to mean (e.g., if it implicitly declares classes
> in the scope of the friendly class, rather than nominating other classes
> as friends), then that code s
Paolo Carlini wrote:
Hi Mark,
I agree; that's why I asked to see the patches.
Humm, maybe a couple of links are in order, for your convenience:
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00681.html
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00679.html
(I understand that Kriang volunteered to
Hi Mark,
> I agree; that's why I asked to see the patches.
Humm, maybe a couple of links are in order, for your convenience:
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00681.html
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00679.html
(I understand that Kriang volunteered to regtest and, if n
Michael Matz wrote:
Hi,
On Sat, 30 Apr 2005, Kriang Lerdsuwanakij wrote:
Sure, this code compiles with 4.1 and 3.4 but doesn't compile with 4.0.
Although the code is valid, I'd bet it doesn't work the way the
programmer of the above code (or other 99% who doesn't track
the standard closely) would
Hi,
On Sat, 30 Apr 2005, Kriang Lerdsuwanakij wrote:
> Sure, this code compiles with 4.1 and 3.4 but doesn't compile with 4.0.
> Although the code is valid, I'd bet it doesn't work the way the
> programmer of the above code (or other 99% who doesn't track
> the standard closely) would expect.
No
Joe Buck wrote:
>I don't quite understand your answer. It seems that (a) is the important
>issue; if the programs are valid, they compiled before, and they worked
>before, then it seems there really is a regression, even if we can argue
>that we were "right by accident" in the past.
>
This is a
Joe Buck wrote:
>>Thanks for your assessment of the problem: indeed, I can tell you for
>>sure that (b) it's true and, as reported by Kriang, the patches are
>>rather simple (but the details of this judgement are up to you, of
>>course). I'm not 100% sure about (a) but Michael can tell you better:
On Fri, Apr 29, 2005 at 10:12:46PM +0200, Paolo Carlini wrote:
> >> I know that, technically, we are not talking about regressions wrt
> >> 3.x, still, important packages that used to compile and, well,
> >> apparently at least, *work* well, now don't even compile (see
> >> c++/19403, c++/21235, ma
Hi Mark,
>> I know that, technically, we are not talking about regressions wrt
>> 3.x, still, important packages that used to compile and, well,
>> apparently at least, *work* well, now don't even compile (see
>> c++/19403, c++/21235, many others linked from there). Would be a big
>> deal having m
Paolo Carlini wrote:
Hi Kriang and Mark,
[ friend PRs snipped ]
I know that, technically, we are not talking about regressions wrt 3.x, still, important packages that used to compile and, well, apparently at least, *work* well, now don't even compile (see c++/19403, c++/21235, many others linked fr
On Apr 29, 2005, at 3:40 PM, Paolo Carlini wrote:
Hi Kriang and Mark,
I know that, technically, we are not talking about regressions wrt
3.x, still, important packages that used to compile and, well,
apparently at least, *work* well, now don't even compile (see
c++/19403, c++/21235, many others
Hi Kriang and Mark,
as you know well, the most important linux distributions and software packages
are currently rebuilt with 4.0 and "weird" problems slowly surface. One of
those is the partial rework of friendship for 4_0, which misses these important
bits present in mainline:
2005-03-14 Kri
The system:
===
uname -a
Darwin localhost 7.2.1 Darwin Kernel Version 7.2.1: Wed Jul 14 03:00:02
PDT 2004; root:tmp/xnu-7.2.1-1-root.obj/RELEASE_I386 x86 i386
gcc -v
Reading specs from /usr/libexec/gcc/darwin/i386/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc.
31 matches
Mail list logo