FW: Introducing the "wincall" Calling Convention for GCC

I present a novel calling convention named "wincall" designed specifically for GCC. This convention is accompanied by the [[__gnu__::__wincall__]] attribute and caters to the latest Intel APX instructions on Windows systems, excluding Linux, BSD, and similar platforms. Motivation: The current

Re: [RISC-V] [tech-toolchain] Fw: [RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Aug 11, 2022)

BEGIN:VCALENDAR PRODID:-//zoom.us//iCalendar Event//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH CLASS:PUBLIC BEGIN:VTIMEZONE TZID:Asia/Singapore LAST-MODIFIED:20220317T223602Z TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Singapore X-LIC-LOCATION:Asia/Singapore BEGIN:STANDARD TZNAME:+08 TZOFFSE

Re: FW: Redesigning the GCC website

> However, the website for the GCC is... shall we say... "bad". No, we shall not say that. We shall in fact loudly compliment the GCC web site as being "very well designed", because it serves exactly the purpose it's meant to serve with minimal distraction, while loading quickly on my slow co

FW: Redesigning the GCC website

Hello! Nothing contained in this email is meant as an attack. The GCC compiler is a wonderful piece of software and by God I'll do anything to avoid writing ASM code. However, the website for the GCC is... shall we say... "bad". It looks outdated compared to the GNU project's homepage. Unfortunatel

Re: FW: ompd_get_thread_id in OMPD implementation

On Sat, Apr 09, 2022 at 12:38:11AM +0200, Ahmed Sayed Mousse wrote: > Sorry for the late reply. > I did check gomp_thread_self but I'm still not sure about what I should do, > maybe because I lack experience/knowledge. > Here is where my thinking is going right now and I hope you tell me if I'm > w

FW: ompd_get_thread_id in OMPD implementation

Sorry for the late reply. I did check gomp_thread_self but I'm still not sure about what I should do, maybe because I lack experience/knowledge. Here is where my thinking is going right now and I hope you tell me if I'm wrong. in gomp_thread_to_pthread_t there are 4 possible outputs 1 - if LIBGOMP

Re: Fw: Regarding __gcov_dump and __gcov_reset usage

On 5/24/21 1:44 PM, Gejoe Daniel via Gcc wrote: Adding gcc mailing list for the clarification. Thank you team !  From: "Gejoe Daniel" Sent: Mon, 24 May 2021 15:02:12 To: "gcc-h...@gcc.gnu.org" Subject: Re: Regarding __gcov_dump and __gcov_reset usage

Fw: Regarding __gcov_dump and __gcov_reset usage

Adding gcc mailing list for the clarification. Thank you team !  From: "Gejoe Daniel" Sent: Mon, 24 May 2021 15:02:12 To: "gcc-h...@gcc.gnu.org" Subject: Re: Regarding __gcov_dump and __gcov_reset usage Hi team, Any info/reply ? Thanking you in adva

FW: Payment Transfer Receipt

-- thanks Proof of payment.html Description: Binary data

Re: Fw: Problems with compiling autogen with GCC8 or newer versions

Hi, On 1/10/21 3:56 PM, Martin Sebor wrote: Sure.  I was confirming that based on the GCC dump there is no risk of an overflow in the translation unit, and so there is no warning. OK. :) I didn't understand the GCC dump. Despite having commit privs, I'm not actually a compiler guru. It can

Re: Fw: Problems with compiling autogen with GCC8 or newer versions

On 1/10/21 12:28 PM, Bruce Korb wrote: Hi Martin, On 1/10/21 11:01 AM, Martin Sebor wrote: On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote: This is the code that must be confusing to GCC. "def_str" points to the second character in the 520 byte buffer. "def_scan" points to a character that we al

Re: Fw: Problems with compiling autogen with GCC8 or newer versions

Hi Martin, On 1/10/21 11:01 AM, Martin Sebor wrote: On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote: This is the code that must be confusing to GCC. "def_str" points to the second character in the 520 byte buffer. "def_scan" points to a character that we already know we're going to copy into the

Re: Fw: Problems with compiling autogen with GCC8 or newer versions

On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote:    $ bash cc.sh    + wrn+=' -Werror=format-overflow'    + gcc -DHAVE_CONFIG_H -I. -I.. -I../autoopts    -Wno-format-contains-nul -Wall -Werror -Wcast-align    -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes    -Wwrite-strings -

Re: Fw: Problems with compiling autogen with GCC8 or newer versions

On 1/8/21 10:39 AM, Bruce Korb via Gcc wrote: > Hi, > > You are supposed to be able to post once you've subscribed. > > Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than > MAXNAMELEN characters. That is provable. > > "def_str" points into a buffer of size ((MAXNAMELEN * 2) +

Re: Fw: Problems with compiling autogen with GCC8 or newer versions

Hi, You are supposed to be able to post once you've subscribed. Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than MAXNAMELEN characters. That is provable. "def_str" points into a buffer of size ((MAXNAMELEN * 2) + 8) and at an offset maximum of MAXNAMELEN+1 (also provable

Fw: دفترهای خاطره

PM GMT+4:30Subject: Fw: دفترهای خاطره - Forwarded message - From: fataneh layeghi To: "tahanoo...@yahoo.com" ; "tahanoor1...@gmail.com" Sent: Saturday, August 29, 2020, 6:27:45 PM GMT+4:30Subject: دفترهای خاطره http://kadousbook.ir/?p=9019 سلام دوستان به رو

Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

by OpenMP outlining (but not IPA split as Honza said). Richard. > -Aditya > > From: Jakub Jelinek > Sent: Monday, March 16, 2020 5:19:16 PM > To: Aditya K > Cc: Jan Hubicka ; gcc@gcc.gnu.org > Subject: Re: Fw: GSoC topic: Implement hot cold s

Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

reuse them. -Aditya From: Jakub Jelinek Sent: Monday, March 16, 2020 5:19:16 PM To: Aditya K Cc: Jan Hubicka ; gcc@gcc.gnu.org Subject: Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level On Mon, Mar 16, 2020 at 11:11:14PM +, Aditya K via Gcc

Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

On Mon, Mar 16, 2020 at 11:11:14PM +, Aditya K via Gcc wrote: > > > > 2) ipa-split is very simplistic and only splits when there is no value > >computed in header of function used in the tail. We should support > > adding extra parameters for values computed and do more general SESE > >

Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

> > 2) ipa-split is very simplistic and only splits when there is no value >computed in header of function used in the tail. We should support > adding extra parameters for values computed and do more general SESE >outlining > Note that we do SESE outlining for openMP but this code is

Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

Hi! On Tue, Mar 03, 2020 at 10:25:32PM +0100, Jan Hubicka wrote: > I think this is bit stronger to what llvm does currently which relies on > outlining SESE regions earlier rather than going through the pain of > implementing support for partitioning. OTOH outlining can result in improved code,

Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

Aditya, the hot/cold partitioning is currently organized as folows: 1) we have static branch prediction code in predict.c and profile feedback which we store into cfg and callgraph. 2) we have predicates optimize_*_for_speed_p/size_p where * can be function, basic block, cfg edge, callg

Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

Hi Martin, Thank you for explaining the status quo. After reading the code of bb-reorder.c,  it looks pretty good and seems it doesn't need any significant improvements. In that case, the only value GIMPLE level hot/cold splitting could bring is to enable aggressive code-size optimization by mer

Fw: Re: sha512.sum for gcc-7.4.0.tar.gz incorrect on at least three mirrors

Many thanks for your extremely prompt help! Regards, Farid Parpia IBM Corporation: 710-2-RF28, 2455 South Road, Poughkeepsie, NY 12601, USA; Telephone: (845) 433-8420 = Tie Line 293-8420 - Forwarded by Farid Parpia/Poughkeepsie/IBM on 06/06/2019 08:24 AM - From: Richard Bie

FW: PROPOSAL: Extend inline asm syntax with size spec

Resend to gcc@gcc.gnu.org to avoid spam filter > From: Michael Matz > > Sent: 07 October 2018 16:53 > ... > > I think the examples I saw from Boris were all indirect inlines: > > > > static inline void foo() { asm("large-looking-but-small-asm"); } > > static void bar1() { ... foo() ... } > >

FW: OpenACC maintainership

Oops, forgot to copy the list. From: Moore, Catherine Sent: Monday, September 10, 2018 4:20 PM To: dje@gmail.com Cc: Schwinge, Thomas ; Philippidis, Cesar ; 'Jakub Jelinek' Subject: OpenACC maintainership Hi David, Following up various conversations that took place at Cauldron over the we

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Torvald, thank you for your output, but I think, this discussion gets a little pointless. There is nothing else I can add since gcc folks are reluctant to this change anyway. In my opinion, there is no compelling reason against such an implementation (it is perfectly fine with the standard, read

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 13:16 +, Ruslan Nikolaev via gcc wrote: > > 3) Torvald pointed out further considerations such as users expecting > > lock-free atomic loads to be faster than stores. > > Is it even true? Is it faster to use some global lock (implemented through > RMW) than a single RMW

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 13:04 +, Szabolcs Nagy wrote: > the solutions is to add a language extension I think this only needs a library interface, at least when we're just considering the __atomic builtins. On the C/C++ level, it might amount to just another atomic type, which only has a CAS how

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 12:56 +, Ruslan Nikolaev via gcc wrote: > But, of course, it is kind of annoying that double-width types (and that also > includes potentially 64-bit on some 32-bit processors, e.g. i586 also has > cmpxchg8b and no official way to read atomically otherwise) need special

Re: Fw: GCC interpretation of C11 atomics (DR 459)

> 1) your proposal would make gcc non-conforming to iso c unless it changes how > static const objects are emitted. I do not think, ISO C requires to put const objects to .rodata. And it is easily solved by not placing it there for _Atomic objects that cannot be safely loaded from read-only m

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On 27/02/18 12:56, Ruslan Nikolaev wrote: Formally speaking, either implementation satisfies C11 because the standard allows much leeway in the interpretation here. no, 1) your proposal would make gcc non-conforming to iso c unless it changes how static const objects are emitted. 2) the two

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Formally speaking, either implementation satisfies C11 because the standard allows much leeway in the interpretation here. But, of course, it is kind of annoying that double-width types (and that also includes potentially 64-bit on some 32-bit processors, e.g. i586 also has cmpxchg8b and no offi

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 22:45 +, Ruslan Nikolaev via gcc wrote: > Thanks, everyone, for the output, it is very useful. I am just proposing to > consider the change unless there are clear roadblocks. (Either design choice > is probably OK with respect to the standard formally speaking, but there

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 10:22 +, Ramana Radhakrishnan wrote: > The way to fix this in AArch64 if there is a > guarantee from the standard that there are no problems with read-only > locations is to implement the change in libatomic. Even though the standard doesn't specify read-only memory, I t

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 19:39 +, Ruslan Nikolaev via gcc wrote: > Torvald, I definitely do not want to insist on this design choice, but it > makes sense to at least seriuously consider it given the concerns I > described. And especially because IFFUNC in libatomic already redirects to > cmpxc

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, Feb 26, 2018 at 10:45 PM, Ruslan Nikolaev via gcc wrote: > Thanks, everyone, for the output, it is very useful. I am just proposing to > consider the change unless there are clear roadblocks. (Either design choice > is probably OK with respect to the standard formally speaking, but there

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Thanks, everyone, for the output, it is very useful. I am just proposing to consider the change unless there are clear roadblocks. (Either design choice is probably OK with respect to the standard formally speaking, but there are some clear advantages also.) I wrote a summary of pros & cons (whi

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Torvald, I definitely do not want to insist on this design choice, but it makes sense to at least seriuously consider it given the concerns I described. And especially because IFFUNC in libatomic already redirects to cmpxchg16b, so it just adds extra cost and indirection. Quite frankly, I do not

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 07:24 +, Ruslan Nikolaev via gcc wrote: > Alexander, > Thank you for your comments. Please see my response below. I definitely do > not want to fight for or against this change in gcc, but there are definitely > legitimate concerns to consider. I think, it would really

Re: Fw: GCC interpretation of C11 atomics (DR 459)

> I'd say the main issue is that libatomic is not guaranteed to work like that. > Today it relies on IFUNC for redirection, so you may (and not "will") get the > desired behavior on Glibc (implying Linux), not on other OSes, and neither on > Linux with non-GNU libc (nor on bare metal, for that ma

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 26 Feb 2018, Ruslan Nikolaev via gcc wrote: > Well, if libatomic is already doing it when corresponding CPU feature is > available (i.e., effectively implementing operations using cmpxchg16b), I do > not see any problem here. mcx16 implies that you *have* cmpxchg16b, therefore > other code

Fw: GCC interpretation of C11 atomics (DR 459)

Alexander, Thank you for your comments. Please see my response below. I definitely do not want to fight for or against this change in gcc, but there are definitely legitimate concerns to consider.  I think, it would really be good to consider this change to make things more compatible (i.e., at

Re: Fw: xz instead of bzip2

TL;DR. The xz format has a long list of defects, and at least some of them are not minor. Please, don't promote such a defective format using it in GCC. Thanks. :-) R0b0t1 wrote: http://lzip.nongnu.org/xz_inadequate.html That article is rather interesting but unfortunately it does not

Fw: xz instead of bzip2

Begin forwarded message: Date: Mon, 5 Jun 2017 20:17:57 -0300 From: Matias Fonzo To: R0b0t1 Subject: Re: xz instead of bzip2 On Mon, 5 Jun 2017 15:44:25 -0500 R0b0t1 wrote: > On Mon, Jun 5, 2017 at 1:08 PM, Matias Fonzo > wrote: > > Dear GCC developers, > > > > What happens here ! > > >

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

On 03/17/2017 05:51 PM, Jim Wilson wrote: On 03/17/2017 04:12 PM, Jim Wilson wrote: I have access to a fast box that isn't otherwise in use at the moment so I'm taking a look. r246225 builds OK. r246226 does not. So it is Bernd's combine patch. A little experimenting shows that the compare d

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

On 03/17/2017 04:12 PM, Jim Wilson wrote: I have access to a fast box that isn't otherwise in use at the moment so I'm taking a look. r246225 builds OK. r246226 does not. So it is Bernd's combine patch. A little experimenting shows that the compare difference is triggered by the use of -gtogg

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

On 03/17/2017 03:28 PM, Jeff Law wrote: On 03/17/2017 03:31 PM, Andrew Pinski wrote: On Fri, Mar 17, 2017 at 11:47 AM, Bernd Schmidt wrote: On 03/17/2017 07:38 PM, Pinski, Andrew wrote: One of the following revision caused a bootstrap comparison failure on aarch64-linux-gnu: r246225 r246226

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

On 03/17/2017 03:31 PM, Andrew Pinski wrote: On Fri, Mar 17, 2017 at 11:47 AM, Bernd Schmidt wrote: On 03/17/2017 07:38 PM, Pinski, Andrew wrote: One of the following revision caused a bootstrap comparison failure on aarch64-linux-gnu: r246225 r246226 r246227 Can you help narrow that down?

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

On Fri, Mar 17, 2017 at 11:47 AM, Bernd Schmidt wrote: > On 03/17/2017 07:38 PM, Pinski, Andrew wrote: >> >> One of the following revision caused a bootstrap comparison failure on >> aarch64-linux-gnu: >> r246225 >> r246226 >> r246227 > > > Can you help narrow that down? I can though I don't want

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

On 03/17/2017 12:47 PM, Bernd Schmidt wrote: On 03/17/2017 07:38 PM, Pinski, Andrew wrote: One of the following revision caused a bootstrap comparison failure on aarch64-linux-gnu: r246225 r246226 r246227 Can you help narrow that down? I'm provisioning an aarch64 system now. jeff

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

On 03/17/2017 07:38 PM, Pinski, Andrew wrote: One of the following revision caused a bootstrap comparison failure on aarch64-linux-gnu: r246225 r246226 r246227 Can you help narrow that down? Bernd

FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

One of the following revision caused a bootstrap comparison failure on aarch64-linux-gnu: r246225 r246226 r246227 Thanks, Andrew Pinski Ignore the URLs in the log file below, this is a Jenkins to Cavium. -Original Message- From: jenk...@cavium.com [mailto:jenk...@cavium.com] Sent: Fri

Re: FW: Question about Gimple FE

On Tue, Apr 7, 2015 at 3:33 AM, Richard Biener wrote: >> Having an IR that is more readable than LLVM's would be nice. > > I still like the idea of using C + extensions most. +1 > As well as making the > -fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting > from dump files to gen

Re: FW: Question about Gimple FE

On Mon, Apr 6, 2015 at 11:20 PM, Sebastian Pop wrote: > On Fri, Apr 3, 2015 at 1:10 PM, Jeff Law wrote: >> On 04/03/2015 09:41 AM, Diego Novillo wrote: >>> >>> On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote: >>> I was hesitant to offer this option, but it's certainly a good >>> starting point.

Re: FW: Question about Gimple FE

On Fri, Apr 3, 2015 at 1:10 PM, Jeff Law wrote: > On 04/03/2015 09:41 AM, Diego Novillo wrote: >> >> On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote: >> I was hesitant to offer this option, but it's certainly a good >> starting point. The representation encodes CFG, SSA, attributes, >> declarati

Re: FW: Question about Gimple FE

On 04/03/2015 09:41 AM, Diego Novillo wrote: On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote: I was hesitant to offer this option, but it's certainly a good starting point. The representation encodes CFG, SSA, attributes, declarations and annotations. It has a relatively fixed syntax, which ma

Re: FW: Question about Gimple FE

On April 3, 2015 5:41:35 PM GMT+02:00, Diego Novillo wrote: >On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote: >> On 04/03/2015 09:30 AM, Diego Novillo wrote: >>> >>> On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong > >>> wrote: >>> So it’s better not to try to read the exact dump format. C

Re: FW: Question about Gimple FE

On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote: > On 04/03/2015 09:30 AM, Diego Novillo wrote: >> >> On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong >> wrote: >> >>> So it’s better not to try to read the exact dump format. >>> Could we use a similar but more complete syntax instead? >> >> >> Absolu

Re: FW: Question about Gimple FE

On 04/03/2015 09:30 AM, Diego Novillo wrote: On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong wrote: So it’s better not to try to read the exact dump format. Could we use a similar but more complete syntax instead? Absolutely. The initial attempt for gimple fe was to use a tuple-based syntax tha

Re: FW: Question about Gimple FE

On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong wrote: >So it’s better not to try to read the exact dump format. >Could we use a similar but more complete syntax instead? Absolutely. The initial attempt for gimple fe was to use a tuple-based syntax that is very easy to parse. But that was only chos

FW: Question about Gimple FE

On 15/4/3 下午11:00, "xue yinsong" wrote: >So it’s better not to try to read the exact dump format. >Could we use a similar but more complete syntax instead? > >—— >Yinsong > >On 15/4/3 下午9:45, "Diego Novillo" wrote: > >> >> >>On 04/02/15 11:59, xue yinsong wrote: >>> I suppose our goal is t

Fw: Results for 4.9.1 (GCC) testsuite on i686-pc-linux-gnu

Dear GCC Team, As there are no test results listed in buildstats page for GCC (4.9.1) for i686-pc-linux-gnu, I am herewith sending the testsuite results. You can list them in buildstats page. Regards, Raghunath Lolur. On Tuesday, 22 July 2014 11:17 PM, Raghu L wrote: I would like to infor

Fw: Results for 4.8.3 (GCC) testsuite on i686-pc-linux-gnu

Dear GCC Team, As there are no test results listed for GCC 4.8.3 in GCC buildstats/testresults page, I am re-sending the test results as below: Regards, Raghunath Lolur. On Tuesday, 1 July 2014 1:41 AM, Raghu L wrote: Dear GCC Team, I would like to inform a successful native bootstrap build

Re: FW: Git repo lagging behing

On Tue, Feb 04, 2014 at 03:59:45PM +, Paulo Matos wrote: > Don't know if anybody noticed but something's wrong with the git repo. It's > lagging behind. Last commit there was: > 18 hours ago tejohnson 2014-02-03 Teresa Johnson > > which was certainly not the last commit on trunk. I b

FW: Git repo lagging behing

Since the owner of the repo http://gcc.gnu.org/git/?p=gcc.git;a=summary is marked as being: gcc@gcc.gnu.org moving this thread of the gcc mailing list. Paulo Matos -Original Message- From: gcc-help-ow...@gcc.gnu.org [mailto:gcc-help-ow...@gcc.gnu.org] On Behalf Of Paulo Matos Sent: 04

Re: Fw: [RE-SENDING]Re: MCSoC2013: to enhance embedded Linux for many-core system

On 18 December 2012 03:06, ETANI NORIKO wrote: > > Of course, we can use GCC on a host core, and we can use MPFR and GMP. > However, as long as we use LD to link object files and create a binary file > for a computing device core, we cannot use MPFR and GMP. > > Here, we would like to ask you as

Fw: Re: [RE-SENDING]Re: MCSoC2013: to enhance embedded Linux for many-core system

-Forwarded message- From: ETANI NORIKO To: iant Date: Sun, 16 Dec 2012 21:34:48 +0900 (JST) Subject: Re: [RE-SENDING]Re: MCSoC2013: to enhance embedded Linux for many-core system Dear Sir, I would like to add my explanation to my former e-mail. >>The reason why GCC is not available f

Fw: [RE-SENDING]Re: MCSoC2013: to enhance embedded Linux for many-core system

-Forwarded message- From: ETANI NORIKO To: iant Date: Sun, 16 Dec 2012 21:26:34 +0900 (JST) Subject: [RE-SENDING]Re: MCSoC2013: to enhance embedded Linux for many-core system Dear Sir, Thank you for replying my e-mail. This is an implementation issue for OpenCL or parallel computing

Fw: Extending calling convention information in DWARF output for x86

Roger From: Michael Eager To: Roger Cruz Cc: "gcc@gcc.gnu.org" ; "dwarf-disc...@lists.dwarfstd.org" Sent: Wednesday, June 6, 2012 1:27 PM Subject: Re: Fw: Extending calling convention information in DWARF output for x86 On 06/06/2012 09:28 AM, Roger Cruz wrote:

Re: Fw: Extending calling convention information in DWARF output for x86

On 06/06/2012 09:28 AM, Roger Cruz wrote: Hi Michael, Thanks for replying to my questions. What I like to obtain somehow is the calling convention of each routine so I can tell who is responsible for cleaning off the stack. Two calling > conventions of interest to me are: _stdcall and _cdecl

Re: Fw: Extending calling convention information in DWARF output for x86

offset: 0x117d6): name      <267c9>   DW_AT_decl_file   : 2     <267ca>   DW_AT_decl_line   : 216       <267cb>   DW_AT_type    : <0x1a509>     <267cf>   DW_AT_location    : 2 byte block: 91 74   (DW_OP_fbreg: -12) How can the above information be u

Re: Fw: Extending calling convention information in DWARF output for x86

On 06/06/2012 06:40 AM, Roger Cruz wrote: Adding dwarf-discuss@ to CC. I am interested in parsing DWARF debug output in order to know the calling convention of each function. Reading the spec for DWARF-4, I can see that there is an attribute DW_AT_calling_convention but its only defined valu

Fw: Extending calling convention information in DWARF output for x86

I am interested in parsing DWARF debug output in order to know the calling convention of each function.  Reading the spec for DWARF-4, I can see that there is an attribute DW_AT_calling_convention but its only defined values are (pg 52): DW_CC_normal DW_CC_program DW_CC_nocall The spec als

Re: FW: is "syslimits.h" likely to change?

On 12/04/2012 16:38, Mark Galeck (CW) wrote: > Thank you Ian, hopefully I will be compatible then for a long time, as > Larry Wall would say "at least until the heat death of the Universe". > > I can't "ignore it" :) My build system cannot handle "include_next" - it > cannot handle the situation

RE: FW: is "syslimits.h" likely to change?

Thank you Ian, hopefully I will be compatible then for a long time, as Larry Wall would say "at least until the heat death of the Universe". I can't "ignore it" :) My build system cannot handle "include_next" - it cannot handle the situation where you are finding a header file in one -I direct

Re: FW: is "syslimits.h" likely to change?

"Mark Galeck (CW)" writes: > GCC has this internal include file "included/syslimits.h".   This file, uses > a non-standard C include directive "include_next" to recursively include > "limits.h" from a second location.  > > I need to change this syslimits.h for our internal use, since I cannot

FW: is "syslimits.h" likely to change?

Hello, GCC has this internal include file "included/syslimits.h".   This file, uses a non-standard C include directive "include_next" to recursively include "limits.h" from a second location.  I need to change this syslimits.h for our internal use, since I cannot easily handle "include_next"

FW: gcc uses too much stack?

Have people considered that stack space should be used more conservatively by gcc? More malloc, less alloca, fewer/smaller local variables? More std::stack or such, less recursion on the machine stack? (Yes, I know std::stack has no existing use in gcc yet.) Don't make the amount of stack used

FW:

for some reason they blocked my very last email, but i tried CC'ing it again, maybe this time they'll let it through. i'm forwarding it to you, since we agree on some points. if it doesn't make it to the mailing list, you might want to forward it, then... or not. thnx -

FW: a nifty feature for c preprocessor

sorry: 2) it takes very little penalty, otherwise.

Re: FW: a nifty feature for c preprocessor

On 28/12/2011 07:48, R A wrote: i'm an amateur programmer that just started learning C. i like most of the features, specially the c preprocessor that it comes packed with. it's an extremely portable way of implementing metaprogramming in C. though i've always thought it lacked a single feature

FW: a nifty feature for c preprocessor

i'm an amateur programmer that just started learning C. i like most of the features, specially the c preprocessor that it comes packed with. it's an extremely portable way of implementing metaprogramming in C. though i've always thought it lacked a single feature -- an "evaluation" feature. s

Re: FW: How to let Linux kernel Makefile generate intermediate *.i files ? It doesn't work to add "EXTRA_CFLAGS += -save-temps" in Makefile and gets "cc: warning: -pipe ignored because -wave-temps sp

On 10/17/2011 09:27 AM, Liu Wang wrote: > > > -Original Message- > From: Liu Wang > Sent: Saturday, October 15, 2011 5:42 PM > To: 'gcc-h...@gcc.gnu.org' > Subject: How to let Linux kernel Makefile generate intermediate *.i files ? > It doesn't work to add "EXTRA_CFLAGS += -save-temps"

FW: How to let Linux kernel Makefile generate intermediate *.i files ? It doesn't work to add "EXTRA_CFLAGS += -save-temps" in Makefile and gets "cc: warning: -pipe ignored because -wave-temps specif

-Original Message- From: Liu Wang Sent: Saturday, October 15, 2011 5:42 PM To: 'gcc-h...@gcc.gnu.org' Subject: How to let Linux kernel Makefile generate intermediate *.i files ? It doesn't work to add "EXTRA_CFLAGS += -save-temps" in Makefile and gets "cc: warning: -pipe ignored becaus

Fw: GFortran download - failure

- Original Message - From: "Franck Z" To: "Mike Du" Sent: Sunday, June 26, 2011 10:53 AM Subject: Re: GFortran download - failure Hello, The Cygwin package has gFortran apparently. It is designed to work directly under Windows. See: http://www.cygwin.com/ Franck

Re: FW: numerical results differ after irrelevant code change

On 5/8/2011 3:01 PM, Michael D. Berger wrote: As I should have said originally, I just did the -march=pentium4 -mfpmath=sse, I didn't change to a 64 bit system. Will that get the repeatabiility? It has on the brief test I did. Right, if you specify sse, you get totally different floating-poin

FW: numerical results differ after irrelevant code change

> -Original Message- > From: Robert Dewar [mailto:de...@adacore.com] > Sent: Sunday, May 08, 2011 13:02 > To: Michael D. Berger > Cc: gcc@gcc.gnu.org > Subject: Re: numerical results differ after irrelevant code change > > On 5/8/2011 12:48 PM, Michael D. Berger wrote: > > > I made the

Re: Fw: RFC: Representing vector lane load/store operations

>> ...Ira would know best, but I don't think it would be used for this >> kind of loop.  It would be more something like: >> >>   for (i=0; i>     X[i] = Y[i].red + Y[i].blue + Y[i].green; >> >> (not a realistic example).  You'd then have: >> >>    compoundY = __builtin_load_lanes (Y); >>    red =

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

Andrew Pinski writes: > On Mon, Nov 29, 2010 at 4:20 PM, Ian Lance Taylor wrote: >> We could decide not to do anything about this, but I don't think it's a >> non-issue.  With -std=gnu++98 g++ accepts this invalid code.  That is, >> it is a g++ extension, and the code is properly rejected with >

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

On Mon, Nov 29, 2010 at 4:20 PM, Ian Lance Taylor wrote: > We could decide not to do anything about this, but I don't think it's a > non-issue.  With -std=gnu++98 g++ accepts this invalid code.  That is, > it is a g++ extension, and the code is properly rejected with > -pedantic-errors.  We could

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

Gabriel Dos Reis writes: > On Mon, Nov 29, 2010 at 3:24 PM, Roman Kononov wrote: >> $ cat test.cc >> struct X { static float const v=1; }; >> >> $ g++ -c -std=gnu++0x test.cc >> test.cc:1:33: error: 'constexpr' needed for in-class initialization of >> static data member 'v' of non-integral type

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

On Mon, Nov 29, 2010 at 3:24 PM, Roman Kononov wrote: > $ cat test.cc > struct X { static float const v=1; }; > > $ g++ -c -std=gnu++0x test.cc > test.cc:1:33: error: 'constexpr' needed for in-class initialization of > static data member 'v' of non-integral type > > This will break a great deal of

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

On Mon, 29 Nov 2010, Andrew Pinski wrote: On Mon, Nov 29, 2010 at 1:24 PM, Roman Kononov wrote: $ cat test.cc struct X { static float const v=1; }; $ g++ -c -std=gnu++0x test.cc test.cc:1:33: error: 'constexpr' needed for in-class initialization of static data member 'v' of non-integral type

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

On Mon, Nov 29, 2010 at 1:24 PM, Roman Kononov wrote: > $ cat test.cc > struct X { static float const v=1; }; > > $ g++ -c -std=gnu++0x test.cc > test.cc:1:33: error: 'constexpr' needed for in-class initialization of > static data member 'v' of non-integral type > > This will break a great deal of

Fw: new requirement of "constexpr" for static const float data members is too restrictive

$ cat test.cc struct X { static float const v=1; }; $ g++ -c -std=gnu++0x test.cc test.cc:1:33: error: 'constexpr' needed for in-class initialization of static data member 'v' of non-integral type This will break a great deal of existing c++ code preventing easy transition to c++0x. Maybe, the

Re: Fw: Debugging plugins with gdb

Daniel/Andrew thanks so much. I was using gdb version 7.1. So it understood deferred breakpoints but as long as I started gdb with something like ~/bin/gcc it never stopped in my function. As soon as I switched to running gdb on cc1, it worked! Now i can work on debugging the seg-fault i'm causin

Re: Fw: Debugging plugins with gdb

On Wed, Aug 11, 2010 at 03:52:17PM -0700, Jeff Saremi wrote: > > Trying to use "break execute_x" command in > > "add-symbol-file myplugin.so" but neither of them work. The > > first one complains that "function not defined" Did it ask you if you want to make the breakpoint pending? If it did,

Re: Fw: Debugging plugins with gdb

On Wed, Aug 11, 2010 at 3:52 PM, Jeff Saremi wrote: > Sending this to "gcc" since I got no help from sending it to "gcc-help" Are you trying to debug gcc or cc1/cc1plus? If the former try running with -v and seeing that cc1/cc1plus is involved and then debug cc1/cc1plus instead. Thanks, Andrew

Fw: Debugging plugins with gdb

Sending this to "gcc" since I got no help from sending it to "gcc-help" --- On Sun, 8/8/10, Jeff Saremi wrote: > From: Jeff Saremi > Subject: Debugging plugins with gdb > To: gcc-h...@gcc.gnu.org > Date: Sunday, August 8, 2010, 9:52 AM > I'd like to step into my plugin to > see if I can debug i

  1   2   >