Re: RFC: Formalization of the Intel assembly syntax (PR53929)

On Fri, 19 Jan 2024, LIU Hao wrote: > ? 2024-01-18 20:54, Jan Beulich ??: > > I'm sorry, but most of your proposal may even be considered for being > > acceptable only if you would gain buy-off from the MASM guys. Anything > > MASM treats as valid ought to be permitted by gas as well (within the >

Re: lambda coding style

On Wed, 10 Jan 2024, Jason Merrill via Gcc wrote: > On 1/10/24 15:59, Marek Polacek wrote: > > On Wed, Jan 10, 2024 at 02:58:03PM -0500, Jason Merrill via Gcc wrote: > > > What formatting style do we want for non-trivial lambdas in GCC sources? > > > I'm thinking the most consistent choice would be

Re: Enable top-level recursive 'autoreconf'

> From: Thomas Schwinge > Date: Thu, 19 Oct 2023 12:42:26 +0200 > It's just GCC and Binutils/GDB, or are the top-level files also shared > with additional projects? Not sure if that counts as "shared", but I regularly drop in* newlib to build simulator targets (*-elf, *-newabi). That's git://sou

Re: [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

t declaration too, which I just changed for consistency-- but it's close enough for me.) With this, retesting plugin.exp for cris-elf works. Ok to commit? -- >8 -- From: Hans-Peter Nilsson Date: Fri, 1 Sep 2023 04:36:03 +0200 Subject: [PATCH] testsuite: Fix analyzer_cpython_plugin.c decla

Re: [committed] exec-stack warning for test which wants executable stacks

> From: Hans-Peter Nilsson > Date: Thu, 26 May 2022 03:17:01 +0200 Regarding setting the default for the RWX-segment warning per-target: > How about the usual method, a line in the ld emulparams > file for the target? JFTR: no extra infrastructure bits needed. I found the right

Re: [committed] exec-stack warning for test which wants executable stacks

> From: Jeff Law via Binutils > Date: Mon, 25 Apr 2022 17:30:59 +0200 > On 4/25/2022 9:26 AM, Nick Clifton wrote: > > Hi Jeff, > > > > Just FYI - I am also looking at adding in another warning. This > > time for > > when the linker creates a PT_LOAD segment which has all of the RWX > > fla

Re: Benchmark recommendations needed

On Mon, 14 Feb 2022, Andras Tantos wrote: > Hello all! > > I'm working on porting GCC to a new processor architecture. I think > I've finally got to a fairly stable stage, so the next logical step > would be to test and optimize. For that, I would need some benchmarks, > and this is where I'm seeki

Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)

Not seeing anyone doing the obvious one-up, so JFTR: On Mon, 10 Jan 2022, David Malcolm via Gcc wrote: > On Mon, 2022-01-10 at 17:13 +0100, FX wrote: > > > FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c > > The purpose of these asm tests is to verify that the analyzer doesn't > get confused by various in

Re: GCC LM32 bug: reordering instructions in stack

On Fri, 1 Oct 2021, Nelson Ribeiro via Gcc wrote: > Hello. > > Firstly I want to apologize for this long post, but in a way this post also > is meant for documenting the work that I have done hunting down this issue. > Secondly I must say that I do not have much insights on the GCC internals, > onl

Re: [PATCH] Port GCC documentation to Sphinx

On Wed, 30 Jun 2021, Eli Zaretskii via Gcc-patches wrote: > > Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org > > From: Martin Li?ka > > Date: Wed, 30 Jun 2021 12:11:03 +0200 > > > 4. Menus lost the short descriptions of the sub-sections. Example: > > > > > >* Designated

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Tue, 15 Jun 2021, Martin Sebor wrote: > On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote: > > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote: > > > > > On 6/11/21 11:32 AM, Jonathan Wakely wrote: > > > > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote: >

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote: > On 6/11/21 11:32 AM, Jonathan Wakely wrote: > > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote: > > > My objection is to making our policies and tools more restrictive > > > than they need to be. We shouldn't expect everyone to study whole > >

Re: New pseudos in splitters

On Wed, 23 Sep 2020, Ilya Leoshkevich via Gcc wrote: > Hi, > > "Defining How to Split Instructions" in gccint states the following: > > The preparation-statements are similar to those statements that are > specified for define_expand ... Unlike those in define_expand, however, > these statements mu

Re: #line directives in generated C files

On Thu, 3 Sep 2020, Hans-Peter Nilsson wrote: > IMHO stepping into the .md really isn't helpful. Even a pattern > name in a comment in the generated code would be better. ...and JFTR, yes I noticed there is, or rather line indicator for example /path/to/mmix.md:211 above gen_add

Re: #line directives in generated C files

On Thu, 27 Aug 2020, Pip Cet via Gcc wrote: > I may be missing an obvious workaround, but it seems we currently emit > a #line directive when including lines from machine description files > in C files, but never emit a second directive when switching back to > the generated C file. This makes step

Re: Clobber REG_CC only for some constraint alternatives?

On Wed, 26 Aug 2020, Pip Cet via Gcc wrote: > Note that whether there is a CC-setting variant depends not just on > the "cc" attr, but also on the precise operands for some values of the > "cc" attr, which requires hairy C code to figure out. > > Is it possible to avoid this situation by avoiding

Re: Clobber REG_CC only for some constraint alternatives?

On Wed, 26 Aug 2020, Jeff Law wrote: > On Tue, 2020-08-25 at 23:58 -0400, Hans-Peter Nilsson wrote: > > On Mon, 24 Aug 2020, Jeff Law via Gcc wrote: > > > On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote: > > > > The post-reload splitter in

Re: Clobber REG_CC only for some constraint alternatives?

On Mon, 24 Aug 2020, Jeff Law via Gcc wrote: > On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote: > > The post-reload splitter introduces the clobber. The wiki > > suggests that approach if most insns clobber REG_CC, perhaps because of > > the missed optimizations you describe

Re: Clobber REG_CC only for some constraint alternatives?

On Thu, 20 Aug 2020, Senthil Kumar Selvaraj wrote: > What I didn't understand was the (set-attr "cc") > part - as far I can tell, this results in (set_attr "cc_enabled" ...) in > all of the three substituted patterns, so I wondered why not just have > (set_attr "cc_enabled" ...) in the original de

Re: Clobber REG_CC only for some constraint alternatives?

On Wed, 19 Aug 2020, Senthil Kumar Selvaraj wrote: > > Hans-Peter Nilsson writes: > > > On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote: > >> As you can deduce from the (set_attr "cc" ..), only constraint > >> alternatives 0,2,3 and 6 clobber

Re: Clobber REG_CC only for some constraint alternatives?

On Sun, 16 Aug 2020, Pip Cet via Gcc wrote: > For example, here's what I currently have: > > (define_expand "mov" > [(parallel [(set (match_operand:MOVMODE 0 "nonimmediate_operand" "") >(match_operand:MOVMODE 1 "general_operand" "")) > (clobber (reg:CC REG_CC))])] > ...)

Re: Clobber REG_CC only for some constraint alternatives?

On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote: > As you can deduce from the (set_attr "cc" ..), only constraint > alternatives 0,2,3 and 6 clobber CC - others leave it unchanged. Yes, I recognize that. > My first version of the port adds a post-reload splitter that adds a > (clobber (

gcc-backport problem on Debian 9

Again, Debian 9. Doing "git gcc-backport a4aca1edaf37d43" on releases/gcc-10 gave me: [releases/gcc-10 83cf5a7c6a5] PR94600: fix volatile access to the whole of a compound object. Date: Sun Jul 5 20:50:52 2020 +0200 9 files changed, 276 insertions(+), 1 deletion(-) create mode 100644 gcc/test

Re: AVR CC0 transition

On Sat, 25 Apr 2020, Eric Botcazou wrote: > > I very much disagree with this. I think my approach was possibly the > > only viable one, and definitely the most sensible one for this target. > > Not only is there nothing meaningful to be gained from separating cc > > setters and users on m68k given

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Thu, 6 Feb 2020, Segher Boessenkool wrote: > Instead of "git am" I had "patch -p1 <", May I suggest "git apply" instead of the good old patch program. (The "-p1" is of course built-in and you never have to do a manual roll-back or separate --dry-run pass.) brgds, H-P

Let's remove all (or the largest) diffs from gcc-cvs@

TL;DR: See subject. Verbosity follows. The git transition is mostly for the better. Thanks to those investing time and effort. There's always fallout. Here's one dustcloud: In the distant past with svn, there messages to gcc-cvs@ were somewhat like git show --stat, i.e. without the actual cha

Using gcc/ChangeLog instead of gcc/testsuite/ChangeLog?

Has there been a change of policy so it's a valid option to use gcc/ChangeLog for testsuite changes? I was about to move a semi-randomly spotted misplaced entry, and when checking if there were others, I noticed that there's like tens of them, so I thought better ask. (IMHO it's confusing to have

Re: MIPS ASAN status? (and "volunteering")

H.J.: please see last. > From: Jean Lee > Date: Sat, 10 Mar 2018 20:22:45 +0800 > > See above regarding looking at patches, but I guess you mean > > that the patch is trivial, so then I presume it was more or less > > the same as this, which is basically a copy-paste from looking > > at rs6000 a

Re: MIPS ASAN status? (and "volunteering")

TL;DR: see last sentence. > From: Jean Lee > Date: Mon, 5 Mar 2018 19:56:59 +0800 > 2018-03-03 21:14 GMT+08:00 Hans-Peter Nilsson : > > > > From: Jean Lee > > > Date: Fri, 2 Mar 2018 13:29:39 +0800 > > > It is great to go the last mile. I had done the

Re: MIPS ASAN status? (and "volunteering")

> From: Jean Lee > Date: Fri, 2 Mar 2018 13:29:39 +0800 > 2018-03-02 7:53 GMT+08:00 Hans-Peter Nilsson : > > > There's no address-sanitizer support for MIPS (in particular for > > O32) on trunk, at least not when building for > > mipsisa32r2el-linux-gnu a

MIPS ASAN status? (and "volunteering")

There's no address-sanitizer support for MIPS (in particular for O32) on trunk, at least not when building for mipsisa32r2el-linux-gnu and libsanitizer/configure.tgt seems to support that observation. There's a set of patches "floating around", but the last sign of work-in-progress was more than f

Re: GCC Buildbot Update - Definition of regression

On Tue, 10 Oct 2017, Paulo Matos wrote: > This is a suggestion. I am keen to have corrections from people who use > this on a daily basis and/or have a better understanding of each status. Not mentioning them (oddly I don't see anyone mentioning them) makes me think you've not looked there so all

Re: [RFD] Extremely large alignment of read-only strings

On Fri, 12 Aug 2016, Thorsten Glaser wrote: > Hans-Peter Nilsson dixit: > > >> ? except -malign-data=abi is, apparently, cris-only. > > >ITYM "i386-only". I see "malign-data=" in > >gcc/config/i386/i386.opt. > > No (actually tested on am

Re: [RFD] Extremely large alignment of read-only strings

On Fri, 12 Aug 2016, Thorsten Glaser wrote: > Dixi quod? > > >Alexander Monakov dixit: > > > >>First of all, I think option -malign-data=abi (new in GCC 5) addresses your > >>need: it can be used to reduce the default (excessive) alignment to just the > >>psABI-dictated value (you can play with thi

Re: basic asm and memory clobbers

On Thu, 26 Nov 2015, David Wohlferd wrote: > On 11/26/2015 8:26 AM, Hans-Peter Nilsson wrote: > > On Thu, 26 Nov 2015, Segher Boessenkool wrote: > > > On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote: > > > > @item noinline ... > > > > a

Re: basic asm and memory clobbers

On Thu, 26 Nov 2015, Segher Boessenkool wrote: > On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote: > > On Fri, 20 Nov 2015, Richard Henderson wrote: > > > I'd be perfectly happy to deprecate and later completely remove basic asm > > > within fu

Re: basic asm and memory clobbers

On Fri, 20 Nov 2015, Richard Henderson wrote: > I'd be perfectly happy to deprecate and later completely remove basic asm > within functions. We've explictly promised (directed to kernel people IIRC) that the empty basic asm; 'asm ("")', has forward-compatible outlining magic, so people would not

Re: Question about macro _GLIBCXX_RES_LIMITS in libstdc++ testsuite

On Thu, 23 Apr 2015, Bin.Cheng wrote: > Hi, > In libstdc++ testsuite, I noticed that macro _GLIBCXX_RES_LIMITS is > checked/set by GLIBCXX_CHECK_SETRLIMIT, which is further guarded by > GLIBCXX_IS_NATIVE as below: > > AC_DEFUN([GLIBCXX_CONFIGURE_TESTSUITE], [ > if $GLIBCXX_IS_NATIVE ; then >

Re: Updating the simtest-howto

On Wed, 8 Apr 2015, Gerald Pfeifer wrote: > On Sun, 30 Dec 2012, Cynthia Rempel wrote: > > I was looking at http://gcc.gnu.org/simtest-howto.html and was wondering > > if the bottom of the page could be modified from links to tests ran in > > 2003 to a link to testresults with a search for sim, lik

Re: Android native build of GCC

On Fri, 6 Feb 2015, Andrew Haley wrote: > On 06/02/15 08:00, Hans-Peter Nilsson wrote: > > On Thu, 8 Jan 2015, Andrew Haley wrote: > >> Android native GCC can't support LTO because of a lack of support for > >> dlopen() in the C library. How should we patch the

Re: Android native build of GCC

On Thu, 8 Jan 2015, Andrew Haley wrote: > Android native GCC can't support LTO because of a lack of support for > dlopen() in the C library. How should we patch the configury to disable > LTO by default? Doesn't setting unsupported_languages in toplevel configure.ac work for you? brgds, H-P

Re: [RFD] Using the 'memory constraint' trick to avoid memory clobber doesn't work

On Thu, 13 Nov 2014, David Wohlferd wrote: > Sorry for the (very) delayed response. I'm still looking for feedback here so > I can fix the docs. Thank you for your diligence. > As I said before, triggering a full memory clobber for anything over 16 bytes > (and most sizes under 16 bytes) makes t

Re: [RFD] Using the 'memory constraint' trick to avoid memory clobber doesn't work

On Thu, 2 Oct 2014, David Wohlferd wrote: > > You want > > > > "=m" (*( struct foo { char x[8]; } __attribute__((may_alias)) *)Dest) > > Thank you. With your help, that worse-than-useless sample in the docs > is getting closer to something people can actually use. Thank *you* for your investigat

Re: Trouble trying to test GCC on a simulator

On Mon, 8 Sep 2014, Pierre-Marie de Rodat wrote: > # Get newlib and the simulator > cvs -d :pserver:anon...@sourceware.org:/cvs/src co newlib sim > # Get binutils > git clone git://sourceware.org/git/binutils-gdb.git > > # Create the combined tree > rm -rf combined > mkd

Re: Question for ARM person re asm_fprintf

On Mon, 21 Jul 2014, David Wohlferd wrote: > I have been looking at asm_fprintf in final.c, and I think there's a design > flaw. But since the change affects ARM and since I have no access to an ARM > system, I need a second opinion. There's this thing called cross-compilation, which happens for

Re: missing symbols in libstdc++.so.6 built from the 4.9 branch

On Tue, 1 Jul 2014, Jonathan Wakely wrote: > On 1 July 2014 20:58, John David Anglin wrote: > > On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote: > > > >> On 1 July 2014 09:40, Matthias Klose wrote: > >>> > >>> - HPPA (build log [2]), is missing all the future_base symbols and > >>> exception_ptr1

Re: linux says it is a bug

On Tue, 4 Mar 2014, Yury Gribov wrote: > Richard wrote: > > volatile __asm__("":::"memory") > > > > is a memory barrier and a barrier for other volatile instructions. > > AFAIK asm without output arguments is implicitly marked as volatile. So it may > not be needed in barrier() at all. Yes, exactl

Re: Where does the gcc_tg.o linked in tests come from?

On Fri, 11 Oct 2013, Brooks Moses wrote: > I'm trying to reproduce a test failure outside the Dejagnu testsuite, > and I noticed that the file I'm trying to recompile is linked with a > gcc_tg.o file. Based on the missing-symbol errors I get when I don't > include it, it seems to provide things l

Re: Delay slot filling - what still matters, and what doesn't matter so much anymore?

(People, please don't use my @gcc.gnu.org address if you need to ping me; not sure why Steven used that. I also changed the other CC'ed addresses to the corresponding relevant one from MAINTAINERS. Looks like I'm month+ behind on reading the lists again... On the plus side, maybe a reply-bump rek

RE: Modeling predicate registers with more than one bit

On Tue, 26 Mar 2013, Paulo Matos wrote: > > -Original Message- > > From: Hans-Peter Nilsson [mailto:h...@bitrange.com] > > Sent: 05 March 2013 01:45 > > To: Paulo Matos > > Cc: gcc@gcc.gnu.org > > Subject: Re: Modeling predicate registers with more tha

Re: Confusion about delay slots and using condition-code register

On Wed, 6 Mar 2013, Alan Lehotsky wrote: > So, am I constructing my RTL incorrectly? No. > Do I need to be > making the clobbers inside a parallel instead of just emitting > them sequentially? Exactly. > (define_insn "*addsi" > [(set (match_operand:SI 0 "nonimmediate_operand" "=rm,r

Re: Modeling predicate registers with more than one bit

On Thu, 28 Feb 2013, Paulo Matos wrote: > Hello, > > I am looking at how to correctly model in GCC predicate > registers that have more than one bit and the value set into to > the predicate register after a comparison depends on the size > of the comparison. > > I have looked into GCC backends but

Re: question about section 10.12

> From: Kenneth Zadeck > Date: Sat, 26 Jan 2013 16:19:40 +0100 > the definition of vec_duplicate in section 10.12 seems to restrictive. > > i have seen examples where the "small vector" is really a scalar. Should > the doc be "small vector or scalar"? Yes. This patch has been sitting in a tree

Re: RFC - Alternatives to gengtype

On Mon, 19 Nov 2012, Lawrence Crowl wrote: > On 11/17/12, Hans-Peter Nilsson wrote: > > On Thu, 15 Nov 2012, Diego Novillo wrote: > > > === Approach: Move GTY to cc1plus. > > > > > > Instead of a separate weak parser, we would make cc1plus > > > unders

Re: RFC - Alternatives to gengtype

On Thu, 15 Nov 2012, Diego Novillo wrote: > === Approach: Move GTY to cc1plus. > > Instead of a separate weak parser, we would make cc1plus > understand GTY attributes. The compiler would emit IL in the > object files instead of generating source. > > This solution would require a first boot stage

Re: Problem running the libgomp testsuite

On Thu, 23 Aug 2012, jojelino wrote: > On 2012-08-20 AM 6:44, Ji?í Pale?ek wrote: > > Hello, > > > > I tried to run "make check-c++" from the top directory of the source > > code. During the run, all of the libgomp tests run by it failed. From > > the log file, you can see that the gcc from the sys

Re: problems in interaction between peephole on CALL_INSN and final_scan_insn

On Sun, 8 Jul 2012, Alan Lehotsky wrote: > I'm certain there are better ways; can you be more specific though? > > Or are you just talking about defining a sibcall_epilogue pattern? I'm not Andrew but I think obviously enough "yes". Better to say, perhaps even document, that text peepholes are de

Re: Ad-hoc notes from the "pending patches" BOF at the GNU tools cauldron.

> From: Dimitrios Apostolou > Date: Tue, 10 Jul 2012 08:25:49 +0200 > Hi hp, thanks for the notes, I'm just going to highlight my point of view. > > Regarding patch pinging, my take is that is should be seldom necessary, > for example I tend to forget my small patches after sometime. Me too, s

Ad-hoc notes from the "pending patches" BOF at the GNU tools cauldron.

On a whim I hosted a BOF at the GNU tools cauldron yesterday, titled "pending patches" (no compliance with RFC5434 intended). This was originally only out of egotistic motives: BUMPing the "Fix gcc.dg/lower-subreg-1.c failure, revisited" patch at

Re: Are we fast yet?

On Thu, 28 Jun 2012, Dimitrios Apostolou wrote: > you may have thought I'd disappeared but here I am, after weeks of working on > a small project of mine. What started as a very small hack for visualising > callgrind's profiles is now an -experimental still- website, a GCC version of > mozilla's "a

Re: HARD_REGNO_CALL_PART_CLOBBERED question (PR53595)

On Mon, 11 Jun 2012, Georg-Johann Lay wrote: > Hans-Peter Nilsson wrote: > > On Fri, 8 Jun 2012, Georg-Johann Lay wrote: > >> I observed that HARD_REGNO_CALL_PART_CLOBBERED gets called with > >> hard registers that HARD_REGNO_MODE_OK would reject.

Re: HARD_REGNO_CALL_PART_CLOBBERED question (PR53595)

On Fri, 8 Jun 2012, Georg-Johann Lay wrote: > I observed that HARD_REGNO_CALL_PART_CLOBBERED gets called with > hard registers that HARD_REGNO_MODE_OK would reject. > > Is it save to set HARD_REGNO_CALL_PART_CLOBBERED to FALSE for > hard registers for which HARD_REGNO_MODE_OK is FALSE? IMHO it sho

Re: array bounds violation in caller-save.c : duplicate hard regs check added

On Fri, 25 May 2012, DJ Delorie wrote: > If I apply this patch, which checks for duplicate hard registers within > -fira-share-save-slots, the following *-elf targets fail due to the assert: > > bfin cris m32c rl78 rx sh sh64 v850 Oop. An no clue as to what's wrong. Can you pretty please m

Re: Option -pthread in test suite with cross compilers

On Fri, 18 May 2012, Ian Lance Taylor wrote: > Joel Sherrill writes: > > > On 05/18/2012 08:27 AM, Ian Lance Taylor wrote: > >> Ralf Corsepius writes: > >> > >>> I am not sure, but AFAICT, -pthread is Linux-specific. > >> It's not properly documented, but -pthread works on a number of hosts, > >>

Re: Option -pthread in test suite with cross compilers

On Fri, 18 May 2012, Joel Sherrill wrote: > I don't mind having -pthread be a noop but the leap > from a having a header file to having a specific gcc > option is a stretch IMO. Unless EVERY gcc target with > pthread support is required by gcc to have that option. > Is that the undocumented(?) inte

Re: Option -pthread in test suite with cross compilers

On Fri, 18 May 2012, Ralf Corsepius wrote: > On 05/18/2012 09:24 AM, Sebastian Huber wrote: > > Hi, > > > > if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11 > > target, then I get several unexpected errors due to: > > > > gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized c

Re: Maybe expand MAX_RECOG_ALTERNATIVES ?

On Fri, 11 May 2012, Greg McGary wrote: > On 05/11/12 16:00, Greg McGary wrote: > > > My question is this: does it make sense to double MAX_RECOG_ALTERNATIVES so > > that I can use insn attributes to identify operand signatures, or should I > > use > > another approach? > > After some exploration,

Re: How do I set SIG_ATOMIC_TYPE to a variant of a C-type?

> From: "Joseph S. Myers" > Date: Tue, 15 May 2012 22:06:03 +0200 > Unless your signal.h does > > typedef __SIG_ATOMIC_TYPE__ sig_atomic_t; I just assumed that was the case, what with other ___xxx_TYPE__ being used throughout the test-suite. My bad. > this should only affect the testcases gcc

How do I set SIG_ATOMIC_TYPE to a variant of a C-type?

I'm considering changing SIG_ATOMIC_TYPE for CRIS (*-elf and *-linux-gnu) to the effect of #define SIG_ATOMIC_TYPE "int __attribute__((__aligned__(4)))" but that by itself doesn't work. It causes a SEGV on the 4.7 branch and no doubt also on trunk; the code is the same. From a gdb session it app

Re: What to do about pattern recognition not in .md order when the mode of a pattern operand is unspecified

> From: Richard Sandiford > Date: Sun, 22 Apr 2012 10:47:24 +0200 > With some trepidation, because I suspect I'm missing the point :-) Maybe but maybe not. Below it seems my observation was misdiagnosed, and this is just a minor bug. > Hans-Peter Nilsson writes: > &g

What to do about pattern recognition not in .md order when the mode of a pattern operand is unspecified

Other target-patches exposed this for me. I have on the 4.7-branch an insn: (jump_insn 245 277 246 (set (pc) (label_ref:SI 312)) whatever.c:511 -1 (nil) -> 187) and two (or more) pattern candidates in the following .md file order: (define_insn "jump" [(set (pc) (label_ref

Re: C++: Letting compiler know asm block can call function that can throw?

On Mon, 2 Apr 2012, Michael Matz wrote: > On Mon, 2 Apr 2012, Jakub Jelinek wrote: > > > > inline int syscall1(int number, long arg1) { > > > register int ax __asm__("eax"); > > > register long di __asm__("rdi"); > > > ax = number; > > > di = arg1; > > > __asm__ volatile ("syscall"); > >

Re: approaches to carry-flag modelling in RTL

s seem to make the most sense. > We shan't do that until we tackle... > > On 11/01/2011 02:59 PM, Hans-Peter Nilsson wrote: > > I'm still thinking of a generic md iterator mechanism (one that > > doesn't restrict the form of the expansion in ways getting in > >

Re: trouble emilinating redundant compares

On Mon, 23 Jan 2012, Paul S wrote: > Thanks Dave, > > I would never have guessed from gccinternals.pdf that it is possible to use > mode iterators to select predicates & constraints ... Really? If you but if you have suggestions for improving the documentation, that'd be welcome. > I think I hav

RE: readonly register

On Sun, 22 Jan 2012, Hans-Peter Nilsson wrote: > On Thu, 19 Jan 2012, BELBACHIR Selim wrote: > > > In fact my final purpose is to replace $INP by a register bank > > in order to be able to read several inputs using pipelined > > instructions (and instruction scheduler)

RE: readonly register

On Thu, 19 Jan 2012, BELBACHIR Selim wrote: > In fact my final purpose is to replace $INP by a register bank > in order to be able to read several inputs using pipelined > instructions (and instruction scheduler). The fixed reg solution > will prevent me from doing this. Is there another way to pr

Re: RTL AND Instruction

On Sun, 22 Jan 2012, Matt Davis wrote: > Once I emit my rtx into the list of insns, GCC gives me an "unrecognized insn" > error. I can trace the code through the first part of the condition, > specified > in i386.md, "ix86_binary_operator_ok," and that passes fine from the > "anddi_1" define_insn

Re: trouble emilinating redundant compares

On Mon, 16 Jan 2012, Paul S wrote: > In the port I'm working on I have used the newer CC tracking technique (i.e. > not cc0). I have followed the directions at the top of compare-elim.c and have > the following pattern for addhi3 > I'm clearly missing something... can anyone provide a hint ? You'

Re: Which Binutils should I use for performing daily regression test on trunk?

> From: Terry Guo > Date: Wed, 21 Dec 2011 04:25:46 +0100 > I plan to set up daily regression test on trunk for target > ARM-NONE-EABI and post results to gcc-testresults mailing > list. Nice. I see others do it for that target, but apparently not for a pristine tree (the results having many fa

Re: building unwind-sjlj.o with / without -fexceptions

On Mon, 5 Dec 2011, Joern Rennecke wrote: > I find that exception handling doesn't work properly for the epiphany with > recent gcc sources (it worked in the pre-merged port with sources from July). > I suppose that is related to the change mentioned in: > http://gcc.gnu.org/ml/gcc-patches/2011-11/

Re: Ad: Fix PR middle-end/45416, missing opt for (a&(1<

On Sun, 11 Dec 2011, Andrew Pinski wrote: > On Sun, Dec 11, 2011 at 3:13 PM, Georg-Johann Lay wrote: > > If there was a canonical representation of these operations, a backend > > wouldn't even notice if the tree passes chose a different, more convenient > > canonicalization. > > The problem is no

Re: Profiling gcc itself

On Sun, 20 Nov 2011, Jeff Evarts wrote: > On Sun, 20 Nov 2011 11:34:27 -0500, Tim Prince wrote: > > On 11/20/2011 11:10 AM, Basile Starynkevitch wrote: > >> On Sun, 20 Nov 2011 03:43:20 -0800 Jeff Evarts wrote: > >>> I posted this question at irc://irc.oftc.net/#gcc and they suggested > >>> tha

libgcc: why emutls.c in LIB2ADDEH instead of LIB2ADD?

As subject says, in libgcc, why is $(srcdir)/emutls.c in LIB2ADDEH (and LIB2ADDEHSTATIC and LIB2ADDEHSHARED) instead of LIB2ADD? Emulating TLS has nothing to do with exception-handling, nor is there something that might throw while calling one of its functions. Ok to fix that? brgds, H-P

Re: bootstrap regression on sparc

On Fri, 11 Nov 2011, David Miller wrote: > > While building libstdc++ I get an assertion failure in haifa-sched.c, > specifically the assertion on line 3437 is failing: > I haven't looked more deeply at it, but the first recent suspicious change > are the basic block handling changes Alan made two

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

On Tue, 8 Nov 2011, Joseph S. Myers wrote: > On Tue, 8 Nov 2011, Hans-Peter Nilsson wrote: > > > (yes, that's you cue. :) For acceptance, IMHO better get it > > working universally by open-coding the implementation without > > requiring --enable-* options. > > M

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

(Not CC:ing the quoted newsgroup, sorry.) On Tue, 8 Nov 2011, David Brown wrote: > If the compiler can generate fractional arithmetic code directly from such > expressions, then it is indeed a good step towards implementing such types as > a pure C++ class without needing to use compiler extension

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

On Sun, 6 Nov 2011, Joern Rennecke wrote: > Quoting David Brown : > > > Take an example using a processor I know well, the AVR (it is an 8-bit > > device, which is a little unusual for gcc). It has an instruction will > > multiply two "1.7" signed 8-bit integers to get a single 1.15 signed > > 16

Re: Dependent Labels Question

On Thu, 3 Nov 2011, Iyer, Balaji V wrote: > Is it possible to make sure that the "LABELX" occurs right > after the "Call some_function" instruction (and the instruction > scheduler moves the label with the call INSN)? I insert the > label right after the call is expanded and LABELX is being moved >

Re: approaches to carry-flag modelling in RTL

Please, when replying, also send to me, not just the list. On Tue, 1 Nov 2011, Paulo J. Matos wrote: > On 01/11/11 02:43, Hans-Peter Nilsson wrote: > > > > Not obvious or maybe I was unclear as to what I alluded? > > In the below insn-bodies, "sub" is the insn tha

Re: approaches to carry-flag modelling in RTL

On Mon, 31 Oct 2011, Paulo J. Matos wrote: > On 31/10/11 05:36, Hans-Peter Nilsson wrote: > > BTW, I > > don't think it helps that someone decided the canonical form of > > a parallel that includes a CC-setter must have the CC-setting > > *first* (contrasti

Re: approaches to carry-flag modelling in RTL

On Sat, 29 Oct 2011, Peter Bigot wrote: > On Fri, Oct 28, 2011 at 11:59 AM, Richard Henderson wrote: > Based on what I've encountered so far, between having to duplicate many > insns (one with CC_REG, one without), adding splits to convert between them, > and making a hash of the templates for the

Re: Target-libiberty being built -- gcc-4.6.1 & gcc-4.6.2

On Sun, 30 Oct 2011, Michael Eager wrote: > On 10/29/2011 11:55 PM, Michael Eager wrote: > > On 10/29/2011 08:44 PM, Ian Lance Taylor wrote: > > > Michael Eager writes: > > > > > > > I'm seeing a build failure when building a bootstrap gcc > > > > because it is attempting to build target-libiberty.

Re: Use of FLAGS_REGNUM clashes with generates insn

On Fri, 23 Sep 2011, Joern Rennecke wrote: > Quoting "Paulo J. Matos" : > > > My addition instruction sets all the flags. So I have: > > This is annoying, but can be handled. Been there, done that. > dse.c needs a small patch, which I intend to submit sometime in the future. Could you be persuad

Re: RFC: Improving support for known testsuite failures

On Thu, 8 Sep 2011, Diego Novillo wrote: > On Thu, Sep 8, 2011 at 04:31, Richard Guenther > wrote: > > > I think it would be more useful to have a script parse gcc-testresults@ > > postings from the various autotesters and produce a nice webpage > > with revisions and known FAIL/XPASSes for the t

Re: Just what are rtx costs?

On Wed, 17 Aug 2011, Richard Sandiford wrote: > It also means > that constants that are slightly more expensive than a register -- > somewhere in the range [0, COSTS_N_INSNS (1)] -- end up seeming > cheaper than registers. Yes, perhaps some scale factor has to be applied to get reasonable cost gr

Re: clobber CC for arithmetic instructions

On Wed, 17 Aug 2011, Rohit Arul Raj wrote: > On Sat, Aug 13, 2011 at 5:20 AM, Hans-Peter Nilsson wrote: > >> On Fri, Aug 12, 2011 at 12:17 PM, Rohit Arul Raj > >> wrote: > >> > Setting the CCR register is done by a built-in function. > > > > Wh

Re: clobber CC for arithmetic instructions

On Fri, 12 Aug 2011, Hans-Peter Nilsson wrote: > On Fri, 12 Aug 2011, Rohit Arul Raj wrote: > Assuming that you can indeed emit reasonable code for compares > and conditional branches without the "CCR register" set to the > do-not-update state, I'd suggest you im

Re: clobber CC for arithmetic instructions

On Fri, 12 Aug 2011, Rohit Arul Raj wrote: > On Fri, Aug 12, 2011 at 12:17 PM, Rohit Arul Raj > wrote: > > Hello All, > > > > I am working on 32-bit target with gcc 4.6.0. I need some help on the > > following: > > > > For my target, If my CCR register is set, all the arithmetic > > instructions

Re: libgcc: strange optimization

On Tue, 9 Aug 2011, Richard Earnshaw wrote: > Better still would be to change the specification and implementation of > local register variables to only guarantee them at the beginning of ASM > statements. Only for those asm statements taking the same asm-register variables as arguments. > At ot

Re: libgcc: strange optimization

On Tue, 9 Aug 2011, Ulrich Weigand wrote: > Richard Earnshaw wrote: > > > Better still would be to change the specification and implementation of > > local register variables to only guarantee them at the beginning of ASM > > statements. At other times they are simply the same as other local > > v

  1   2   3   >