Re: Cross compile, no grmic/grmiregistry

> On Thu, 2005-11-10 at 14:05 -0700, TJ Laurenzo wrote: > > Call me silly, I don't really know how and where to file a PR. Is there > > any guideline? > I just realized that I referred you to a PR and you had asked what > that meant. It is a record in the GCC Bugzilla database: > http://gcc.gnu.o

Re: non-ambiguous typedefs

h-in-progress for the fact that ambiguous declarations are reported as non-existant. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: [RFC] PR C++/24138

unds using a number of the same precision as the set of valid indices, so edge-case representations require a little special handling. (Of course, that whole function is busted if we get an array of a size that can't be represented in a HOST_WIDE_INT, but that's not your problem...) -- Mark

Link-time optimzation

ts develop the technical plan. The document is on the web here: http://gcc.gnu.org/projects/lto/lto.pdf The LaTeX sources are in htdocs/projects/lto/*.tex. Thoughts? -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Link-time optimzation

ly think of > anything you've forgotten. Thanks! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Register Allocation

getting comments before starting implementation. I'm glad to see that strategy taking hold as a general approach for major development initiatives. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: [RFC] PR/24900: computed but not used cast values

rybody happy? > > I think so. FWIW, I agree with all of RTH's comments in this thread. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: pruning unused debugging types (enums/PR23336)

y for the kinds of types we tend to lose (maybe casts and enums?), to keep the extra memory cost to a minimum. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

GCC 4.1/4.2 Status Report (2005-11-18)

for 4.2 within a couple of months? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: GCC 4.1/4.2 Status Report (2005-11-18)

Diego Novillo wrote: > On Friday 18 November 2005 03:48, Mark Mitchell wrote: > > >>I would like to better understand the status of GOMP; is it going to be >>ready for 4.2 within a couple of months? >> > Most definitely. We have been essentially waiting for

Re: GCC 4.1/4.2 Status Report (2005-11-18)

Diego Novillo wrote: > Yes. The mental model is something like this: Makes sense. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: pruning unused debugging types (enums/PR23336)

Aldy Hernandez wrote: > Either way is fine by me. Just to make sure I understand things; > you want me to hack the front-end to fill the hash table every time > it parses a cast or enum type? Yes. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

GCC 4.1 branch created

complete the checklist and send out information about 4.2 Stage 1; that will happen within the next thirty minutes. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: GCC 4.1 branch created

Mark Mitchell wrote: > I am still working through the remainder of the branch checklist. I believe that I have now completed the checklist, with the exception of: # Generate the next mainline snapshot manually, using the -p option of the gcc_release script. For that single run, adjust

GCC 4.2

c math routines library * Vectorization Enhancements, Parts 2 and onwards. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: GCC 4.2

Gabor Loki wrote: > Mark Mitchell wrote: > >> I've reviewed the GCC 4.2 projects on the Wiki. >> >> It certainly looks like some exciting stuff is in the pipeline. > > > I hope it is not too late to merge the Code Factoring Optimizations branch > in

Re: trees

> @c Trees > @c- > > @node Macros and Functions > @subsection Trees > @cindex tree > > This section is not here yet. I have no idea If I wrote that (I'm not disbelieving, I just don't remember), it was many years ago. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: [RFC] fixproto and canadian cross builds

use_fixproto=yes in config.gcc, which somewhat surpises me; I'd have thought newlib didn't require that. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: [RFC] fixproto and canadian cross builds

it's not like anybody would notice > anything even in cases where it did run. That's comforting. I'd rather hoped that newlib wouldn't require fixing... So, Paul, perhaps the short answer is "turn it off for 68k and check that it doesn't seem too broken." --

Re: Default arguments and FUNCTION_TYPEs

reed to kill it, although I don't know if it was actually removed. If that's been done, there's no longer any reason. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: overcoming info build failures

Ben Elliston wrote: > I tracked this build problem of mine down. I expect others will > experience it, too, hence this posting. If you're building from > clean, you won't have this problem. Sorry about that! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Default arguments and FUNCTION_TYPEs

Gabriel Dos Reis wrote: > Assuming the extension was gone, do you see a reason we not move the > default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use > TREE_VEC instead of TREE_LIST to hold the parameter-type list? Both things sound OK to me. -- Mark Mitchell CodeSour

Re: GCC-3.4.5 Release Status

Gabriel Dos Reis wrote: > Mark, RTH, could you provide hints? I don't have any ideas, just from looking atthe problem. It could be a stack allocation problem, where we assign two things the same stack slot, and get confused. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Performance regression testing?

s in the same way that we treat ordinary test failures, but maybe something like this would help us to keep our eye on the ball. Again, that's a strawman. I'm just looking for suggestions about what we might to do -- or even feedback that there's no need to do anything. Thanks, --

Re: Performance regression testing?

man, perhaps we could add a small integer program (bzip?) and >>a small floating-point program to the testsuite, and have DejaGNU print >>out the number of iterations of each that run in 10 seconds. > > Would that really catch much? I really don't know. That's why it&

Torbjorn's ieeelib.c

to get the FSF involved in any way before including the code? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Torbjorn's ieeelib.c

t should be no problem (other than the > delay) to do new paperwork, and maybe RMS would be OK with it going in > now as long as we're sure that everything will be done by release time. > > But I do think we have to ask. Shucks. Should I ask [EMAIL PROTECTED] or RMS directly or ..

Re: Torbjorn's ieeelib.c

David Edelsohn wrote: > Swox AB does have a copyright assignment on file, so GCC is free > to use ieeelib.c. Great. Thanks for double-checking! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Torbjorn's ieeelib.c

end up going in the other order, unless someone steps up to do the libgcc move shortly. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Torbjorn's ieeelib.c

would indeed need a change to include them in libgcc. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: incomplete type return types

27;s the bug. It should change the return type to error_mark_node, and then the code that check returns should be silent in that case. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Torbjorn's ieeelib.c

upport to save code size, although there are probably also users that would make use of support for these features. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: pr14516 and GCC 3.4

Gunther Nikl wrote: > Hello! > > This PR is about missing USER_LABEL_PREFIX for static variables. The issue > was fixed for 4.0, but for 3.4 there won't be a fix as stated in the audit > trail by Mark Mitchell in comment #15. He probably based his decision on > comment #

Re: Torbjorn's ieeelib.c

t wanted to migrate. Joseph is comparing the two alternatives with fp-bit.c, and I'd expect he'll have an opinion about which is best. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Torbjorn's ieeelib.c

ute looks best. At this point, we have convincing ieeelib.c numbers, but I don't think we have GLIBC soft-fp data yet. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: [C++] cp_token::type and cp_token::keyword

r_peek_nth_token (parser->lexer, 2); > else > token2.type = token2.keyword = RID_MAX; > > It looks to me like the last line is a typo for > > { > token2.type = CPP_EOF; > token2.keyword = RID_MAX; > } Yes. The obvious patch is pre-approved.

LTO, LLVM, etc.

I hope that we'll continue to improve Tree-SSA in the meanwhile. There are some nice projects in the works, and I'd like to encourage people to keep working on them. Moving algorithms from Tree-SSA to LLVM will no doubt be tractable, and we'll be able to benefit from new Tree-SSA optimizations, if/until LLVM is integrated. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Installing libgcj consumes huge amounts of memory

re library. We are pushing make a bit too hard it seems. This might be caused by my patch to reduce compile time in classpath. I know I tested memory use back then, but this might have only been with respect to the gcj invocations. I'll try reversing this patch and retest later today or tomorrow. Bu

GNU Classpath development and gcc integration

f the core libraries without disrupting the normal gcc development flow. More details about the setup can be found in the libjava/HACKING file in svn. We try really hard not to disrupt the normal flow of GCC development. For any large build/integration changes we contact Mark Mitchell as release ma

Re: Installing libgcj consumes huge amounts of memory

On Sun, 2005-12-04 at 11:48 +0100, Mark Wielaard wrote: > This might be caused by my patch to reduce compile time in classpath. I > know I tested memory use back then, but this might have only been with > respect to the gcj invocations. I'll try reversing this patch and retest &g

Re: LTO, LLVM, etc.

d you've captured my point (that this effectively reduces the cost of LTO, since it provides something else we want) nicely. Again, I don't think that's a definitive argument; it's just one item to factor in to the overall decision. THanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: LTO, LLVM, etc.

Steven Bosscher wrote: > On Saturday 03 December 2005 20:43, Mark Mitchell wrote: > >>There is one advantage I see in the LTO design over LLVM's design. In >>particular, the LTO proposal envisions a file format that is roughly at >>the level of GIMPLE. Such

Re: LTO, LLVM, etc.

but that I do agree that one wants the right representation for the job, and that Tree-SSA is not the best representation for optimization. So, if Tree-SSA is not replaced, it will almost certainly need to evolve. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: LTO, LLVM, etc.

ractice is part of its type), its name (for debugging), its location relative to the stack frame (if we want to be able to do optimizations based on the location on the stack, which we may or may not want to do at this point), and whatever mark bits or scratch space are needed by optimization passes.

Re: LTO, LLVM, etc.

and of itself a problem -- but I'm happy to switch to LLVM, if we think that it's easier to make LLVM do what we want than it is to make Tree-SSA do what we want. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: LTO, LLVM, etc.

hared was not. That's why I think we should be talking about the effort required to implement the approaches before us, and the payoffs from where those approaches lead us, rather than generalities about design. (And, if you really want a prize, you can put "risk-adjusted" in fron

Re: C++ parser: Should we get rid of cp_parser_declarator_id?

nction? As Gaby says, perhaps we could mark the function inline, if you're worried about performance? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Nathan Sidwell as Morpho Technologies Co-Maintainer

The SC has approved Aldy's nomination of Nathan as a co-maintainer for the Morpho Technologies port. Nathan, please updated MAINTAINERS. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Installing libgcj consumes huge amounts of memory

Hi Gerald, On Mon, 2005-12-12 at 00:21 +0100, Gerald Pfeifer wrote: > On Sun, 4 Dec 2005, Mark Wielaard wrote: > >> 2005-09-21 Mark Wielaard <[EMAIL PROTECTED]> > >> > >> * lib/split-for-gcj.sh: Cut list to 3 package levels deep. > > I rever

Re: g++.dg/ext/packed3.C

s code to be invalid, and either issue a diagnostic, or at least be considered undefined behavior. (In my idea world, ptr->m has type "packed Foo" in this case, and it's not permissible to binding a "packed Foo" to a "Foo const&", so this would be invalid, but I could live with undefined.) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: g++.dg/ext/packed3.C

Nathan Sidwell wrote: > Mark Mitchell wrote: > >> struct Foo { void operator=(Foo const &);}; >> struct Baz __attribute__((packed)) >> { >>char c; >>Foo m; >> } >> >> void Bar (Baz *ptr) >> { >>ptr->m = s

Bootstrap comparison failure

rap GCC, I'm obviously missing something, so any hints would be appreciated. Mark

Re: Bootstrap comparison failure

> Date: Sun, 18 Dec 2005 11:49:37 -0500 > From: Daniel Jacobowitz <[EMAIL PROTECTED]> > > On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote: > > Looks like the new toplevel bootstrap infrastructure broke > > bootstrapping on OpenBSD. I get a bootstrap

#pragma pack vs. zero-width bitfields

a few days. So, any disagreements? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1 Status Report (2005-12-19)

ntention is to create the first 4.1 release candidate when (a) we've eliminated the P1s, and (b) it's at least January 19th. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713

Re: Will there be a GCC 4.0.3 ?

begin work on that release shortly. The GCC 4.0.x branch is stable, so it's relatively easy to make a release. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713

Re: RTL alias analysis

the load. My guess at a solution is that when A (with alias set S_a) and B (with alias set S_b) are given the same stack slot, we should create a new alias set S_c which is a subset of both S_a and S_b, and give the combined stack slot that aliase set. -- Mark Mitchell CodeSourcery, LLC [EMAIL P

Re: C++ parsing regression?

ecl. Was this > change intended? I'm not sure; please send me preprocessed source, and I will look into it. It's certainly possible that those changes broke something. What do you think the above code is supposed to mean? Are you declaring a constructor for CflFunctor, or an unname

Ben Elliston appointed libdecnumber maintainer

Ben -- The GCC SC has appointed you as a maintainer of libdecnumber. Please add yourself to MAINTAINERS. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: C++ parsing regression?

up, and to look at this bug. Thanks for the analysis regarding the cause; that should help. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [C++] enumerators and check_initializer

E (decl)) != REFERENCE_TYPE); > > where one wanted to check that the decl is not a reference type? Yes. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Cleanups of TARGET_EXPR

he cleanups should not be run. However, if it were just "b ? TARGET_EXPR : something", then the cleanups should be run; that would be an orphaned use. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Cleanups of TARGET_EXPR

o that f will construct the value directly into s. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Not using VAR_DECLs for temporary variables

k we should do the complete patch. I know it's going to be tedious to fix the uses of SSA_NAME_VAR, but I think that would be much cleaner, and will also avoid problems where we have a DECL (GVAR_DECL) that is missing fields that other parts of the compiler might expect a DECL to have. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Why don't we stop the optimizer pipeline when errorcount > 0?

s you say, it's just a recipe for trouble to be doing any code generation at all when errors have ocurred. At worst, we miss some diagnostics -- which we will then issue when the user recompiles after fixing whatever errors they had in the original code. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1 Status Report (2006-01-15)

n about a week of RC1; if there are problems reported for RC1, then we'll iterate. Therefore, if there are other regressions which you would like to see fixed for 4.1, now is the time! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.0 Status Report (2006-01-15)

hat 4.1.0 is in reasonably good shape. After 4.0.3 has been released, I do not plan to make any more releases from the 4.0 branch, although (as with previous branches) another RM may step in to do that. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 Status Report (2006-01-15)

ments. Therefore, while we will enter Stage 1 as scheduled, we'll permit those projects already on the 4.1 projects list to be submitted and/or reviewed during Stage 2. However, because we will be in Stage 2, other patches of similar magnitude will need to wait until until GCC 4.3. -- Mar

Importing GNU Classpath 0.20

will import this now into the libjava directory on the trunk. Please let us know ([EMAIL PROTECTED]) if there are any issues with the new import. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath

Re: -Wpointer-sign for GCC 4.1

nce you seem to have a handle on the outcome of the discussion, would you please create a Bugzilla entry for this, targeted at 4.1, explaining what it is the SC agreed to do? Otherwise, I'm certain to forget about this issue... Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: What's GNU -- and what's not

e final document as can be seen here: https://wiki.gnu.tools/gnu:gsc-feedback > The wiki that they set up "for GNU maintainers" represents them We setup gnu.tools on request of several GNU maintainers. Please see https://wiki.gnu.tools/start and https://wiki.gnu.tools/wiki:admin to see how it works and if you want to use it. Cheers, Mark

Re: Not usable email content encoding

d body and passing through the DKIM signatures): https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html Cheers, Mark

Re: Automatically generated ChangeLog files - script

On 04/05/2020 20:28, H.J. Lu via Gcc wrote: On Mon, May 4, 2020 at 12:24 PM Tobias Burnus wrote: On 5/4/20 9:05 PM, Jakub Jelinek via Gcc wrote: On Mon, May 04, 2020 at 08:56:16PM +0200, Martin Liška wrote: What's missing right now is how will we declare a Backport format. Can we just use s

Re: New x86-64 micro-architecture levels

uinfo (but could). I think it is important to be precise here, because in the past this has sometimes caused confusion. For example for how to check correctly for avx, lzcnt, or fma[4] support. Thanks, Mark P.S. I don't particular like the numbered names, but well, bike-shed...

Re: Future debug options: -f* or -g*?

Hi David, On Mon, 2020-08-31 at 20:10 -0700, David Blaikie wrote: > Hey Mark - saw a little of/bits about your presentation at LPC 2020 GNU > Tools Track (& your thread on on the gdb list about debug_names). Wondering > if you (or anyone else you know who's contributing to

Re: Split DWARF and rnglists, gcc vs clang

erpretations of DWARF, but I > > don't really follow the gdb implementation details very much. Could we > > maybe move discussions like these from the -patches list to the main > > gdb (or gcc) mailinglist? > > Sure, I added gdb@ and gcc@. I also left gdb-patches@ so that it's > possible to follow the discussion there. Thanks, Mark

Re: Split DWARF and rnglists, gcc vs clang

r a "main" Dwarf or "split" Dwarf. The only thing it doesn't do yet is share the file handle between the Dwarf object (which isn't strictly needed, but would be a nice optimization). I actually think having a "single" split-dwarf file (.o == .dwo) is the best way to support Split Dwarf more generically because then it would simply work without having to adjust all build systems to work with/around separate .dwo files. Cheers, Mark

Re: DWARF64 gcc/clang flag discussion

n, or whether you need another -goption to explicitly turn on debuginfo generation when using -gdwarf32/64? My preference would be that any option starting with -g enables debuginfo generation and no additional -g is needed to keep things consistent. Cheers, Mark

Re: DWARF Debug Info Relocations (.debug_str STRP references)

ower_su| > > 10babf58 70 70 6c 79 5f 67 65 74 5f 64 72 76 64 61 74 61 > |pply_get_drvdata| > 10babf68 00 5f 5f 6b 73 74 72 74 61 62 5f 70 6f 77 65 72 > |.__kstrtab_power| > > Have I misunderstood something fundamental here about the relocation data in > .rela.debug_info and its application...? Or is the relocation data in this > .rela.debug_info bad...? I would be very surprised if the relocations generated by GCC are bad. I don't know whether the tools you are using to dump the data apply the relocations already or not. Which could explain why applying the relocation again might seem wrong. Cheers, Mark

Re: DWARF64 gcc/clang flag discussion

and line flags where a later flag can override an earlier flag. Cheers, Mark

Re: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references)

ELF image even though they are no longer needed (and if you do try to use/apply them, you get wrong results). We should probably find out if this happened during the upstream build or during distro packaging. Cheers, Mark

Re: Non-dwarf blocks detected by valgrind

e a patch for that: https://code.wildebeest.org/git/user/mjw/valgrind/commit/?h=dwarf5 It needs a little bit more cleanup, but should already work as expected. Cheers, Mark

Re: Non-dwarf blocks detected by valgrind

On Mon, 2021-01-25 at 15:38 +0100, Mark Wielaard wrote: > On Mon, 2021-01-25 at 15:05 +0100, Thomas Koenig via Gcc wrote: > > --4184-- WARNING: Serious error when reading debug info > > --4184-- When reading debug info from > > /home/ig25/lib64/libquadmath.so.0.0.0: >

Re: DWZ 0.14 released

le that gets referenced from all the given object files. Technically the first optimization could be done by the linker. But the second optimization is really a post-linker step. Cheers, Mark

Re: Remove RMS from the GCC Steering Committee

the long history of problematic behavior it would be good for the Steering Committee to consider whether it still wants to be associated with the FSF. And whether to remove or replace RMS on the steering committee. Thanks, Mark

Re: Remove RMS from the GCC Steering Committee

al letter is here: https://rms-open-letter.github.io/ Sometimes satire is a way to deal with difficult problems, but I don't think that is appropriate here and I hope people take these issues seriously, because I think they are. Mark

Re: Remove RMS from the GCC Steering Committee

ects, including the compilers, glibc, libstdc++, the potential > upcoming Rust implementation, and more until this problem is not > "address", but *fixed*. If you never fix it, I will never return. > > Wish you and your community all the best in sorting this out, Thanks. I do hope we can finally fix this and welcome you back. Cheers, Mark

Re: Remove RMS from the GCC Steering Committee

lting torrent of misogynistic and racist posts were truly shocking. He turns a community into a toxic and hostile place when people question his authority by implying such people must be the enemy of Free Software or GNU and that they must be stopped. Cheers, Mark

Re: Remove RMS from the GCC Steering Committee

our friends do. In which case it is better to simply step aside. Various FSF board members already left, or promised to leave, to make way for a new generation of leaders, please take inspiration from them, they are also fiercely dedicated to Free Software and believe it is time for a fresh start. Thanks, Mark

Re: Remove RMS from the GCC Steering Committee

itigate this incident. It happened, that is painful enough. Again, it isn't about this one or two incidents. I am sure someone can find a way to explained it away by saying people simply misunderstood his intentions or that no law was broken. But it is about a pattern of behavior that shows RMS creates a misogynist, racist and transphobic environment by (hopefully unknowingly) setting the example that others will then follow and amplify. Cheers, Mark

Re: Remove RMS from the GCC Steering Committee

point here. If GCC is going to disassociate itself from the FSF it needs to find a different fiscal sponsor and legal guardian for the project and that would be a good time to re-formalize the GCC Steering Committee setup. But I also think David is right. Be careful what you wish for :) Cheers, Mark

GCC association with the FSF

h the FSF. The GNU Assembly is having a similar discussion right now https://lists.gnu.tools/postorius/lists/assembly.lists.gnu.tools/ Cheers, Mark

Re: GCC association with the FSF

Hi David, On Wed, Apr 07, 2021 at 10:04:21AM -0400, David Malcolm wrote: > On Wed, 2021-04-07 at 00:22 +0200, Mark Wielaard wrote: > > I admit it isn't looking very good and their last announcement is > > certainly odd: https://status.fsf.org/notice/3833062 > > >

Re: Proposal for merging scalar-storage-order branch into mainline

there and I don't know how to get the svn branch. So I don't know if this question is easily satisfied by the code already by just looking at the dwarf2out.c changes. If so, my apologies and please just point me at the patch or commit. Thanks, Mark

How to find (svn/git) branches. (Was: Proposal for merging scalar-storage-order branch into mainline)

On Mon, 2015-06-08 at 16:04 +0200, Andreas Schwab wrote: > Mark Wielaard writes: > > > I am sorry, I normally use the git mirror and this branch doesn't seem > > to be there and I don't know how to get the svn branch. > > http://gcc.gnu.org/git/?p=gcc.gi

CFCs

Sent from my iPhone

Re: Repository for the conversion machinery

> kgallowa = Kyle Galloway > He's at twitter now, but I don't have an email address. These all worked on GNU Classpath and gcj, but I don't have a current email address for them. > fitzsim = Thomas Fitzsimmons > No clue. Not with Red Hat anymore Works at Cisco now. fitz...@fitzsim.org Cheers, Mark

Re: Debugger support for __float128 type?

> Date: Wed, 30 Sep 2015 19:33:44 +0200 (CEST) > From: "Ulrich Weigand" > > Hello, > > I've been looking into supporting __float128 in the debugger, since we're > now introducing this type on PowerPC. Initially, I simply wanted to do > whatever GDB does on Intel, but it turns out debugging __fl

Re: gnu-gabi group

. Having a local gnu-gabi group on sourceware.org would be better IMHO. Cheers, Mark

Re: gnu-gabi group

On Mon, 2016-02-15 at 13:37 -0200, Alexandre Oliva wrote: > On Feb 12, 2016, Pedro Alves wrote: > > > On 02/11/2016 06:20 PM, Mark Wielaard wrote: > >> If we could ask overseers to setup a new group/list gnu-gabi on sourceware > >> where binutils, gcc, gdb, glib

<    2   3   4   5   6   7   8   9   10   11   >