On Wed, 2005-05-25 at 03:03 +0200, Gabriel Dos Reis wrote:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
>
> | On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote:
> | > | So you don't see any value whatsoever to having (for instance) the
> | > | individual con
On Wed, 2005-05-25 at 01:45 +0200, Paolo Carlini wrote:
> >.. However, the active development on the
> >libstdc++.so.7 branch means that we haven't even started the clock
> >running on this criterion yet.
>
> Maybe a clarification is in order: actually, the name
> libstdcxx
On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote:
> On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
> > Well, if I were running the show, the 'clock' would only start running
> > when it was consensus among the libstdc++ developers that the sonam
On Tue, 2005-05-24 at 20:27 -0400, DJ Delorie wrote:
> > This is still not an answer to the question I originally asked - do you
> > see any way IN C to write code which has the relevant property of the
> > class above (that is, that the FOOmode constants are not accessible
> > except to authorized
On Tue, 2005-05-24 at 20:54 -0400, DJ Delorie wrote:
> > This doesn't do what I want at all. The goal is to make the *symbolic
> > enumeration constants* inaccessible to most code.
>
...
> If it's OK to have the enums in a header, provided you can't *use* them...
>
> enum {
> #ifdef TVQ_AUTHORIT
R Hill <[EMAIL PROTECTED]> writes:
> Joe Buck wrote:
>> [The request to create a login] also helps assure that the bug
>> filer is a real person. If Bugzilla provided an anonymous way to
>> file Bugzilla reports, we'd probably have spammers filling the bug
>> database with ads for penis enlargemen
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> gensupport.c:1122: undefined reference to `insn_elision_unavailable'
> gensupport.c:975: undefined reference to `n_insn_conditions'
> gensupport.c:977: undefined reference to `insn_conditions'
> collect2: ld returned 1 exit status
>
>
> This is an ins
Mark Mitchell <[EMAIL PROTECTED]> writes:
> I would be in favor of making the mode always explicit, as you suggest
> -- but I would prefer that we not embed the assumption that the
> default mode is 64-bit mode in x86-64.h so that we can continue to use
> that file for 32-bit default compilers. (
Richard Henderson <[EMAIL PROTECTED]> writes:
> On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote:
>> Or, if GAS can be told which mode it should be in via directives in
>> its input (.code32/.code64?), then we could add something like
>>
>> f
Sergei Organov wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
>
>>Sergei Organov writes:
>> > Hi,
>> >
>> > Using gcc compiled from gcc-4_0-branch, in an attempt to see which
>> > particular optimization option makes my test case to be mis-optimized, I
>> > try to replace -O1 (which toggles
Jakub Jelinek wrote:
> I have posted a patch that implements it, but it hasn't been reviewed
> (yet). If it ever goes in (which would be certainly after 4.0.1 release),
> the next step would be to modify gettext again to grok it.
I sent you a revision yesterday, have you had a chance to look at i
Kelley Cook wrote:
> In my local tree, I've updated all the files copyrights with the new FSF
> address (a.k.a. GNU Public License 2, rev 3). This change has already
> been preapproved. I figured committing this in the lull of the GCC
> Summit would be a good time as any.
>
> My question is can
"wangxiuli" <[EMAIL PROTECTED]> writes:
> Hi some errors appear when compiling gcc-3.4.4 and gcc-4.0.0 on i386
> freebsd -5.2.1.those errrors are caused by byacc's convention of
> arguments .how to solve them?
You must use Bison; we do not support byacc.
zw
George R Goffe <[EMAIL PROTECTED]> writes:
> tail: cannot open `+16c' for reading: No such file or directory
> tail: cannot open `+16c' for reading: No such file or directory
> tail: cannot open `+16c' for reading: No such file or directory
You have the buggy version of coreutils that does not re
Kaveh R. Ghazi said:
> Hmm I'm curious, what systems (if any) have fprintf_unlocked?
At the time I thought glibc had it, but I don't see it on my (2.3.5)
system now.
baffled,
zw
Nix said:
> On 14 Aug 2005, Zack Weinberg yowled:
>> Kaveh R. Ghazi said:
>>> Hmm I'm curious, what systems (if any) have fprintf_unlocked?
>>
>> At the time I thought glibc had it, but I don't see it on my (2.3.5)
>> system now.
>
> It doesn&#
[I apologize for breaking the thread; I am currently stuck using a web-mail
client that does not permit manual insertion of References: headers. Please
don't take this comment as a sign that I am resuming participation in GCC
development in general.]
Joseph Myers:
> There are plenty of spare bits
Joseph S. Myers said:
> On Fri, 16 Sep 2005, Zack Weinberg wrote:
>> I am with Joe Buck in the opinion that even a 1% performance penalty for
>> implementing (A) [or (B)] would be too much -- I suggest this be fixed by
>> convincing the C++ committee to allow (C) an
Gabriel Dos Reis said:
> "Zack Weinberg" <[EMAIL PROTECTED]> writes:
> | When the standard is arguably buggy -- if nothing else, it diverges from C
>
> C++98 came before C99, so who diverged from whom?
It doesn't matter. The divergence should be resolved in f
Gabriel Dos Reis said:
> "Zack Weinberg" <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis said:
> | > C++98 came before C99, so who diverged from whom?
> |
> | It doesn't matter.
>
> Yet, you're you were construeing it as an argument to suppor
Gabriel Dos Reis said:
[...]
> Good. It seems to me like those who would be spending a great deal of
> time and money are not sufficiently convinced by your arguments.
> Consequently, it appears that they are not in position to explain your
> strong opinion to the committees -- personally, I'm not
> > We can now identify the exact version of gcc t have simply by the
> > revision number and branch name. So maintaining all this stuff in a
> > DATESTAMP, etc, is severe overkill when you could simply use the result
> > of "svnversion .' and commit that to a file, or do it client side).
>
> I th
> printf(“Hello World\n”); is UB under -fexec-charset= EBCDIC. WTF WTF!!!
It's not undefined behavior. It does, however, appear to trip various
bugs in GCC.
$ cat test.c
#include
int main(void) { printf("hello world\n"); }
$ gcc-9 --version | head -n1
gcc-9 (Debian 9.3.0-18) 9.3.0
$ gcc-9 -fex
Over the past couple months I have been working on adding a function to
glibc for erasure of sensitive data after it's used. This function
already exists in various other libraries under various names --
explicit_bzero, explicit_memset, SecureZeroMemory, memset_s,
OPENSSL_cleanse, etc -- and the pr
[Sorry for the double-post, but I got the LLVM mailing list address wrong,
and I want to make sure that everyone sees the entire conversation.]
Over the past couple months I have been working on adding a function to
glibc for erasure of sensitive data after it's used. This function
already exists
OK, I have now failed to find the LLVM development list twice in a
row. Could some kind soul please forward the message to whereever the
heck the proper address is?
zw
On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
> You're making this harder than it needs to be. The "m" constraint is
> the wrong thing to use here. Simply use:
>
> __asm__(""::"r"(ptr):"memory");
Please review my earlier conversation with Adhemerval on exactly this point.
zw
On 09/09/2015 12:52 PM, paul_kon...@dell.com wrote:
> Then again, suppose all you had is explicit_bzero, and an annotation
> on the data saying it's sensitive. Can static code analyzers take
> care of the rest? If so, this sort of thing doesn't need to be in
> the compiler.
The thing that absolu
On 09/09/2015 01:13 PM, Rich Felker wrote:
> On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote:
>> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
>>> You're making this harder than it needs to be. The "m" constraint is
>>&g
On 09/09/2015 02:02 PM, paul_kon...@dell.com wrote:
>> On Sep 9, 2015, at 1:54 PM, David Edelsohn
>> wrote:
>>
>> What level of erasure of sensitive data are you trying to ensure?
>> Assuming that overwriting values in the ISA registers actually
>> completely clears and destroys the values is d
>In a recent upgrade, we noticed that -I- functionality is being
>replaced with -iquote. This -iquote does not have the same
>functionality as -I- and is removing a strong function that is needed.
I wasn't around for the decision to remove the "don't search the
directory containing the current fi
On Mon, Jan 23, 2006 at 11:13:26AM -0800, Richard Henderson wrote:
> This is reproducible with an i686 cross.
Urgh. And I've got Geert reporting a crash (in a different place)
on ppc-darwin.
I won't be able to do anything until I get home, at 4 or 5 Pacific.
If you/anyone feels like fixing it so
On Mon, Jan 23, 2006 at 03:04:25PM -0500, Andrew Pinski wrote:
> >
> > On Mon, Jan 23, 2006 at 11:13:26AM -0800, Richard Henderson wrote:
> > > This is reproducible with an i686 cross.
> >
> > Urgh. And I've got Geert reporting a crash (in a different place)
> > on ppc-darwin.
>
> I was able to
On Mon, Jan 23, 2006 at 03:16:56PM -0500, Andrew Pinski wrote:
> >
> > That's the genextract crash that rth is seeing on ppc-linux. Can you also
> > reproduce the ppc-darwin genautomata crash?
>
> Nope. genautomata just works.
Clarification please. In a cross configuration targeting ppc-darwin
On Mon, Jan 23, 2006 at 03:28:59PM -0500, Andrew Pinski wrote:
> >
> > On Mon, Jan 23, 2006 at 03:16:56PM -0500, Andrew Pinski wrote:
> > > >
> > > > That's the genextract crash that rth is seeing on ppc-linux. Can you
> > > > also
> > > > reproduce the ppc-darwin genautomata crash?
> > >
> >
On Mon, Jan 23, 2006 at 03:46:10PM -0800, Richard Henderson wrote:
> Got it.
Looks good to me. (Argh, I thought I had caught all of the places where
I made that mistake.) Are you going to check it in?
And here's the fix for genautomata, which had two bugs. One was a
simple case of assuming tha
On Mon, Jan 23, 2006 at 10:39:19PM +0100, Marcin Dalecki wrote:
>
> Inside genautomata.c there is a function gen_regexp_el(). It's
> allocating
> a regexp_t by calling create_node(). However the code looks like:
>
> else if (strcmp (str, NOTHING_NAME) == 0)
> {
> regexp = create_nod
On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote:
> Andreas Tobler wrote:
> >I get the following bootstrap break on solaris 8:
> >
> >cc1: warnings being treated as errors
> >insn-automata.c: In function 'internal_insn_latency':
> >insn-automata.c:1969: warning: implicit declaration o
On Tue, Jan 24, 2006 at 10:29:08PM -0500, Kaveh R. Ghazi wrote:
> I'm getting the following new bootstrap failure on both
> sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for
> stage1:
>
> > "build/gencondmd.c", line 1943: warning: syntax error: empty initializer
> > "build/gen
On Tue, Jan 24, 2006 at 11:55:32PM -0500, Kaveh R. Ghazi wrote:
> Okay, now I get:
[...]
>"build/gencondmd.c", line 60: incomplete struct/union/enum c_test:
> insn_conditions
>"build/gencondmd.c", line 1952: warning: syntax error: empty initializer
>"build/gencondmd.c", line 1952: can
On Wed, Jan 25, 2006 at 10:17:40AM -0800, Steve Ellcey wrote:
> > 2006-01-25 Andreas Tobler <[EMAIL PROTECTED]>
> >
> > * genautomata.c (main): Add insn-config.h and recog.h to the
> > include list.
> > * Makefile.in (insn-automata.o): Adjust dependencies for the above
>
On Wed, Jan 25, 2006 at 01:01:17PM -0800, Steve Ellcey wrote:
>
> I took Zack's advice and put all the includes from insn-attrtab.c into
> insn-automata.c. My current problem is that I get:
>
> | insn-automata.c: In function 'print_reservation':
> | insn-automata.c:22466: warning: string length
On Wed, Jan 25, 2006 at 02:10:33PM -0800, Steve Ellcey wrote:
>
> It seems to be coming from the reservation_names array set up in
> print_reservation. One of the entries is:
>
> "(1_0m_bs,1_m_cont)|(1_0mi_bs,1_mi_cont|nothing)|(1_0mm_bs,1_mm_cont)|(1_0mf_bs,1_mf_cont|nothing)|(1_0b_bs,1_b_cont|
On Wed, Jan 25, 2006 at 04:13:02PM -0800, Steve Ellcey wrote:
>
> I see, in an older GCC build output I see a compilation of
> insn-attrtab.c and I get the messages:
>
> /proj/opensrc/sje/svn/gcc.patch/trunk/gcc/config/ia64/itanium2.md: In
> function 'print_reservation':
> /proj/opensrc/sje/svn/
On Tue, Feb 28, 2006 at 10:02:03PM +0100, Gerald Pfeifer wrote:
> That said, I don't really disagree about enforcing proper prerequisites to
> build GCC and its documentation, my question in this case, and in general,
> just is: Can the issue which we encountered be worked around in a simple
> wa
My patch to allow defining constraints in the machine description rather
than with tm.h macros has been on mainline for a week now with no serious
problems reported. Now would be a good time to start converting ports.
Conversions are easy, but are best done by port maintainers, as
careful testing
Since mainline is now in bugfixes only mode, and since port conversions
have been being more troublesome than I had hoped, I think it makes sense
to start a branch now to queue up port conversions until the next release
cycle. I can undertake to do periodic mainline-to-branch merges (no more
frequ
It's an interesting system. I wonder if it's powerful enough to express
the rather complicated constraints on objects of type va_list. Warnings
for violations of those constraints would be valuable - there are common
portability errors that could be caught - but it's never been important
enough t
> I think that CPP should try to determine the encoding for each file
> and not use a single encoding for every file. It should look for
> a unicode header when it opens a file (original c source or any
> include), and if it doesn't find one, use the default: -finput-charset,
> LC_CTYPE, UTF-8, un
On Thu, Apr 27, 2006 at 05:16:10PM -0700, Joe Buck wrote:
> On Thu, Apr 27, 2006 at 07:58:29PM -0400, Zack Weinberg wrote:
> [ Unicode, UTF-{8,16}, BOMs, etc ]
> > It would also be good to take advantage of the fact that 95+% of C
> > source files start with "/*&q
The runtime of what, gcc or fixincludes? Whatever solution we come up
with, I'd like to avoid duplicating setting STDC_0_IN_SYSTEM_HEADERS,
i.e. bad idea to do it once in gcc and once in fixincludes. Better is
if we can include the target config file somehow.
Let's not go down the road of incl
On 10/2/06, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:
> Let's not go down the road of including the target config file in
> more places which are not part of the compiler proper - which are
> not even inside the gcc directory!
I agree, but I also want to avoid duplicating the info in two plac
On Fri, 2005-02-11 at 20:29 -0500, Daniel Berlin wrote:
> On Fri, 2005-02-11 at 20:25 -0500, Nathanael Nerode wrote:
> > (For a new, all-svn branch, there are easier ways of keeping track of that
> > revision number, like putting it in the log message for the merge.)
>
> Or using svnmerge, which d
Back in 2006 I added a mechanism for defining machine-specific
constraints in the MD file rather than with C macros. This mechanism
offers several advantages over the old way of doing it, but until all
ports are converted, we can't actually implement some of those -- most
important, perhaps, is th
On 5/28/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
Just in case you've forgotten: You posted a patch for h8300 here:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html>
Yes, but it's got bugs, and it will be more efficient for an actual
h8300 expert to fix them than for me
I'm trying to help DJ with converting m32c to define_constraint, and
I'm running into an unrelated problem. Specifically, the unmodified
compiler targeting m32c-elf, in -mcpu=m32cm mode, crashes on any use
of __builtin_va_start, even this:
int foo(int x, ...)
{
__builtin_va_list t;
__builtin_v
I'll try your patch, but I would still like to know whether we
couldn't stop using make_tree altogether, just expand valist and then
pass it to emit_move_insn (or maybe convert_move would be better).
zw
On 7/5/07, Zack Weinberg <[EMAIL PROTECTED]> wrote:
I'll try your patch, but I would still like to know whether we
couldn't stop using make_tree altogether, just expand valist and then
pass it to emit_move_insn (or maybe convert_move would be better).
Patch does not help.
On 7/5/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> libstdc++'s bitmap_allocator.cc, because for some reason reload wants
> a MODE_PARTIAL_INT mode with 64 bits. There is no such mode, so
> get_smallest_mode_for_size aborts. I am attaching the .lreg and .greg
> dumps to this message (compress
On 05 Jul 2007 18:22:50 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Zack Weinberg" <[EMAIL PROTECTED]> writes:
[std_expand_builtin_va_start]
> rtx va_r = expand_normal (valist);
> emit_move_insn (va_r, nextarg);
>
> but this is a part of the comp
During development of the patch I just posted for double-word clz, I
went through all the back ends and audited their use of the bit-scan
named patterns and RTL. It appears to me that our current handling of
C[LT]Z_DEFINED_VALUE_AT_ZERO is much more complicated than it needs to
be, and also that
Richard Kenner wrote:
* Since no one uses it, we rip out all support for the ffs pattern and
expression.
There's an ffs builtin! How do we know who uses it?
I am not proposing to remove the built-in (i.e. the language visible
__builtin_ffs() function); only the RTL expression (ffs:MODE ...)
Andrew Pinski wrote:
On 8/15/07, Zack Weinberg <[EMAIL PROTECTED]> wrote:
Is popcount really slow on PowerPC? (Compared to clz?)
popcount is really popcount in bytes and then you do a multiple to get
the real popcount. This is why it is slower than count leading zeros.
Also popcoun
Segher Boessenkool wrote:
* I would like to do the same for __builtin_ctz, but there is a catch.
The synthetic ctz sequence in terms of popcount (as presently
implemented by ia64.md, and potentially usable for at least i386 and
rs6000 as well if moved to optabs.c) produces the canonical behavior
Joern Rennecke wrote:
The score, sh and sparc instructions may or may not display canonical
behavior; their ports do not define CLZ_DEFINED_VALUE_AT_ZERO and I was
not able to find documentation of the relevant instruction.
The operation the nsb instruction of the SHmedia instruction set perfor
I suppose this is related to what I said to you on IRC, so I ought to
chime in here.
I agree with Daniel and David - your patch is not appropriate. As
long as we actually have the .l and .y files, the associated .c/.h
files should not be checked in, and flex/bison should be required when
building
Lijuan Hai wrote:
>
> I have a plan to convert UCN to alphabet instead of UTF8 in
> GCC-4.2.0, and already handled it in libcpp.
I would like to offer advice, but I don't understand what you are
trying to do. You say you want to "convert UCN[s] to [an] alphabet
instead of UTF8" but that doesn't m
On Fri, Sep 17, 2021, at 9:36 PM, James Y Knight via Libc-alpha wrote:
> Glibc currently implements bcmp as an alias to memcmp -- which is valid,
> but provides more than just the boolean equality semantics. There was
> concern raised that modifying that might break existing binaries. However,
> th
I’m the closest thing Autoconf has to a lead maintainer at present.
It’s come to my attention (via https://lwn.net/Articles/913505/ and
https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
Clang both plan to disable several “legacy” C language features by
default in a near-future
On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>> While everyone else is discussing big ideas, it would be helpful for me
>> personally if autoconf just made a release with the latest bugfixes.
>
> Before I dive into the rest of this thread
Nick Bowler writes:
> My gut feeling is that Autoconf should just determine the necessary
> options to get compatible behaviour out of these modern compilers, at
> least for the purpose of running configure tests. For example, Autoconf
> should probably build the AC_CHECK_FUNC programs using gcc'
Rich Felker writes:
> On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote:
>> The biggest remaining (potential) problem, that I’m aware of, is that
>> AC_CHECK_FUNC unconditionally declares the function we’re probing for
>> as ‘char NAME (void)’, and asks the compil
Florian Weimer writes:
> based on a limited attempt to get this fixed about three years
> ago, I expect that many of the problematic packages have not had their
> configure scripts regenerated using autoconf for a decade or more. This
> means that as an autoconf maintainer, you unfortunately won'
Paul Eggert writes:
> On 2022-11-10 19:33, Zack Weinberg wrote:
>
>> It would be relatively easy for me to take a couple hours this
>> weekend and put out a 2.72 release with everything that's already in
>> trunk and nothing else. Anyone have reasons I _shouldn
Sam James writes:
>> On 12 Nov 2022, at 03:40, Zack Weinberg wrote:
>> This is definitely more work than I can see myself doing on a volunteer
>> basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
>> cherry pick the changes needed to support
Wookey writes:
> On 2022-11-10 19:08 +0100, Florian Weimer wrote:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more. This
>> means that as
On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>>
>> Although there will be problems with people who run "./configure
>> CFLAGS='-Werror'", that sort of usage has always been problematic and
>> unsupported by Autoconf, so we can simply contin
On Wed, Nov 16, 2022, at 1:17 PM, Paul Eggert wrote:
...
> If Clang's threatened pickiness were of some real use elsewhere, it
> might be justifiable for default Clang to break Autoconf. But so far we
> haven't seen real-world uses that would justify this pickiness for
> Autoconf's use of 'char
I've been trying to fill in as many gaps as possible in the config.sub
test suite (and finding a whole bunch of actual bugs in the process).
I have a short list of inputs where the actual code to handle them is
incomplete or broken, there's nothing in config.guess to use as a clue,
and I don't know
101 - 179 of 179 matches
Mail list logo
