ore I approve it.
H.J., could you update your patch to support --with-arch/cpu=native as
Uros requested?
Jason
On 04/06/2010 09:39 AM, Kirill A. Shutemov wrote:
On Tue, Apr 6, 2010 at 3:16 PM, Jakub Jelinek wrote:
The GCC 4.5 release branch has been finally created today.
Please, add gcc-4_5-branch to git mirror.
Done.
Jason
believe the conceptgcc-branch is more current than the
cxx0x-concepts-branch.
Jason
x27;t know its current status.
Jason
-pedantic-errors will make it an error.
I don't feel strongly about whether these should be pedwarn or something
stronger, but I note that libstdc++ wants to use variadic templates in
the default mode, so we can't just disable them entirely.
Jason
fications are a failed feature, and nobody is particularly
interested in fixing them.
> It should also be very
easy to add a switch to instruct G++ to ignore all exception
specifications when generating code, if necessary.
There is one already: -fno-enforce-eh-specs
Jason
Chris Lattner wrote:
On Apr 10, 2009, at 1:55 PM, Jason Merrill wrote:
My impression is that the C++ committee generally feel that exception
specifications are a failed feature, and nobody is particularly
interested in fixing them.
Have you seen this?
http://www.open-std.org/JTC1/SC22/WG21
> Vincent Lefevre writes:
>while ((*(q++))-- == 0) ;
Is that defined and legal?? Is q incremented before or after *q is
decremented? They are both post operators!
Jason Mancini
_
Rediscover Hotmail®: Get e-mail storag
nlikely(enabled)) {
}
}
If i call 'trace(ptr->arg1, ptr->arg2)', then the pointers are
dereferenced before the 'if' is executed. Is there any way to delay the
argument evaluation until they are used? Am I missing a compiler option?
I am used gcc 4.3.0.
thanks,
-Jason
Also the remotes are in a different place from where
git-svn puts them, though I suppose that's easy enough to adjust when
fetching.
Jason
gcc
would be the way to go.
Jason
ds in gcc.git, and just map its remotes into
my remotes by manually specifying remote.origin.fetch. Not very pretty,
but it seems to produce the optimal result. See my stuff in the lower
section of http://gcc.gnu.org/wiki/GitMirror for more details.
Jason
On 06/15/2009 10:28 AM, Rafael Espindola wrote:
It fails with
$ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*'
That's not my section; my contribution starts at
Alternative git-svn procedure (Jason Merrill)
Jason
svn could be configured to map svn branches directly to the
local namespace instead of remotes/ ?
It could, but it seems unnecessary.
Jason
Incidentally, I notice that branches in subdirectories of branches/ are
still broken; i.e. ARM apple redhat suse ubuntu, maybe others. I give
instructions on the GitMirror page for how to deal with that, but I
wonder if it's possible to set it up properly on the mirror instead.
Jason
I also notice a few remotes with @ in them like milepost-bra...@129596
which seem to be git-svn artifacts.
Jason
ror in git with separate git-svn
fetch lines rather than use the branches= line.
Jason
On 06/20/2009 04:38 AM, Bernie Innocenti wrote:
On 06/20/09 04:59, Jason Merrill wrote:
Any thoughts on what to do about the non-branch directories under
branches/? The complete set is ARM apple csl dead gcj ibm ix86 suse
ubuntu. The only solution I can think of would be to specifically
On 05/11/2010 10:30 AM, H.J. Lu wrote:
I created a branch for 256bit vectorizer, branches/vect256/. Richard
and I will work on it to extend vectorizer to 256bit.
Jason, can you include it in git mirror? We can drop the ix86 branch
in git since there are several branches under branches/ix86
On 05/11/2010 11:21 AM, H.J. Lu wrote:
On Tue, May 11, 2010 at 7:49 AM, Jason Merrill wrote:
git config --add remote.origin.fetch
refs/remotes/vect256:refs/remotes/origin/vect256
git config --add svn-remote.svn.fetch
branches/vect256:refs/remotes/origin/vect256
I was hoping
git
ne.
http://repo.or.cz/w/official-gcc.git
still fetches refs/heads, not refs/remotes. I can't browse branches
under refs/remotes.
True.
Jason
yield the original pointer value.
Jason
on the mailing lists.
I'll take a look at this soon.
Jason
specifier_seq
instead of cp_parser_type_specifier_seq and then wait to complain about
defining a type until after we've seen the ':'.
Jason
ecifier is not one of the expansions, so we don't
treat a { as beginning a class body. In the case of a
type-specifier-seq, we do treat it as beginning a class body, but we
give an error about it.
Jason
l need a new overload resolution function. 2.14.5 tells
you how it works; look at the overload set, see if it contains a
particular signature, and build up a normal call as appropriate.
Jason
former gives a more useful diagnostic.
I think the right answer is, as you say, to split up
cp_parser_simple_declaration so we can share the
cp_parser_decl_specifier_seq call between the two cases.
Jason
different from plain x.
17.6.3.3.5 User-defined literal suffixes
[usrlit.suffix]
Literal suffix identifiers that do not start with an underscore are reserved
for future standardization.
Ah, thanks.
Jason
On 11/05/2010 09:03 PM, Gabriel Dos Reis wrote:
I'm looking into std::bitset with respect to constexpr issue.
My understanding has always been that one can use the
syntax `member()' to value-initialize an array data member
`member'.
I believe so.
Jason
that requires a constant expression is ill-formed; in C
it's merely undefined.
Jason
don't think unsigned arithmetic can overflow in C/C++.
Ah, so I was missing something, thanks!
Jason
us:
extern template __attribute ((visibility ("default")) int f(int);
In a PR Geoff asked if we really want to allow different visibility for
different instantiations. I think we do; perhaps one instantiation is
part of the interface of an exported class, but we want other
instantiations to be generated locally in each shared object.
Jason
aration/definition model. We ignore the #pragmas
for implicit instantiations because the user doesn't control the point
of instantiation; with explicit instantiations, they do.
Explicit instantiations don't behave just like implicit instantiations;
there are other differences.
Jason
m VC++ will tend to default to hidden
visibility, but make the interfaces default visibility. If a particular
instantiation of a template is part of the interface of a non-template
class, it must also get default visibility.
Jason
ther
namespace-scope declaration (class, function or template). I think
that'll be more straightforward than making a subtle distinction between
class members and template specializations.
Jason
these before bugs that actually
affect users. I'd knock them down to P4.
Jason
Benjamin Smedberg wrote:
Jason, I'm sorry to email you directly, as I don't know which email list
I should be discussing on. I've built gcc trunk after your visibility
patch landed, and there are some serious issues with compiling Mozilla now:
Take the following code:
clas
(copying your mail to the gcc mailing list again)
Benjamin Smedberg wrote:
Jason Merrill wrote:
It seems that you have a different mental model of type visibility.
The way I was thinking about it, if a type has hidden visibility, we
can't refer to it from outside its object. Thu
Benjamin Smedberg wrote:
Jason Merrill wrote:
Do you agree with implicitly giving template instantiations the
minimum visibility of the template and arguments unless explicitly
overridden?
This is not what I would naturally expect, coming from a
dllimport/export mindset, but I don't
#x27;t be referenced from outside their defining object. The
visibility restrictions place practical limits on how other objects can
use the type, but that doesn't mean it isn't the same type.
Jason
Gabriel Dos Reis wrote:
Jason Merrill <[EMAIL PROTECTED]> writes:
So, -concretely- what happens to a class S (e.g. associated type info object
address, address of member functions, etc.) with external linkage,
defined in multiple translation units, with say hidden visibility?
If it has
d get link errors on others
is a very strange default interpretation.
It shouldn't matter. The public members of a class should all have
default visibility if any do. But that's a coding standards issue.
Jason
been around as long as people have tried to use shared libraries
with C++?
Jason
Geoffrey Keating wrote:
Jason Merrill <[EMAIL PROTECTED]> writes:
Benjamin Smedberg wrote:
Also, do you agree with warning about a class with greater
visibility than its data members/bases?
Sure... I would really like to disable this warning if possible,
since it will be pr
On Wed, 16 Feb 2005 14:34:59 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:
> A binary search has led to the cause of a serious regression on
> mainline with gfortran at *all optimization levels (ie., -O0, -O1
> and -O2)*. The problematic commit is
>
>2005-02-13 J
On Wed, 16 Feb 2005 15:13:09 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 16, 2005 at 05:44:44PM -0500, Jason Merrill wrote:
>> On Wed, 16 Feb 2005 14:34:59 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:
>>
>> > A binary search has led to
is that the transformations fold_indirect_ref_1
is doing on arrays don't mix well with how fortran handles arrays. Could
someone familiar with the fortran frontend take a look at that function?
Jason
t that's true, but as Neil says your example
does not support that claim. Textually reproducing an input line in a
diagnostic is very different from reconstructing it in the pretty-printer.
Jason
; but are we still doing that?
Anonymous namespaces don't have random names on ELF targets anymore.
Jason
as now -gdwarf-4 is the default.
Jason
On 03/30/2013 02:23 AM, Senthil Kumar Selvaraj wrote:
I couldn't find a way to ask gcc to just generate DWARF (default
version) either. How should this be fixed?
Maybe we could use -gdwarf for that now, since we stopped using it for
DWARF 1 in GCC 3.4.
Jason
On 04/02/2013 09:07 AM, Senthil Kumar Selvaraj wrote:
Ok, how about the following (tentative) patch? If -gdwarf- is
specified without any argument, it picks DWARF 4 as the default.
-gdwarf- looks a bit odd to me; I was thinking -gdwarf without the
trailing -.
Jason
should have Negative(gdwarf-).
I don't think you need a dwarf_default_version variable since there's
already dwarf_version.
It would be nice to give a helpful diagnostic if people try to write
-gdwarf2 to suggest that they either write -gdwarf-2 or -gdwarf -g2.
Jason
make the gdwarf option
handling code detect this error, the only I found was to make it
JoinedOrMissing, and then raise the error if there was an argument
provided.
That sounds clean enough to me.
Jason
ambiguous; "
+ "use %<-gdwarf-%s%> for DWARF version "
+ "or %<-gdwarf -g%s%> for debug level", arg, arg, arg);
OK with that change, thanks.
Jason
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html
once the post-meeting mailing is released, or I can send you a copy if
you'd like to see it sooner.
Jason
On 04/22/2013 12:42 PM, Jason Merrill wrote:
The proposal will be at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html
It's now been posted at http://isocpp.org/files/papers/N3649.html
Jason
in the past, and/or was the intersection
of refs/remotes/* and refs/heads/* meant to be the empty set (then I
assume the merging would work, too), but no longer is?
Hmm, it looks like I wrote that up without actually doing it myself,
oops. I'll correct the wiki.
Jason
, for
backward compatibility with existing users?
Do we want to limit creation of non-personal branches via git?
Any other thoughts?
Jason
On 07/22/2013 04:59 PM, Diego Novillo wrote:
On Mon, Jul 22, 2013 at 4:39 PM, Jason Merrill wrote:
I'd like to make some changes to the GCC git-svn mirror. Specifically, I
want to move all the SVN branches from remotes/ into heads/ and split the
subdirectory branches (redhat, google
farg3.C,
which would be a problem itself.
Yep, I'll deal.
Jason
On 08/05/2013 03:40 PM, Marek Polacek wrote:
On Mon, Aug 05, 2013 at 11:34:55AM -0700, Linus Torvalds wrote:
On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
wrote:
Ugh. I can see the attraction of your section thing for that case, I
just get the feeling that we should be able to do better some
understand.
Thanks,
-Jason
On 08/05/2013 04:35 PM, Richard Henderson wrote:
On 08/05/2013 09:57 AM, Jason Baron wrote:
On 08/05/2013 03:40 PM, Marek Polacek wrote:
On Mon, Aug 05, 2013 at 11:34:55AM -0700, Linus Torvalds wrote:
On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
wrote:
Ugh. I can see the attraction of
> Status
> ==
> GCC 4.8.1 has been released, the branch is again open
> for regression bugfixes and documentation fixes.
> GCC 4.8.2 could be tentatively released in early September.
Curious user is curious about 4.8.2 status! :^)
in current Darwin require this extension (more generally,
there are existing bodies of code that require this feature)? (Also, if
someone were to implement support for the OpenCL C language in GCC, OpenCL
2.0 requires blocks.)
Yes, similarly.
Jason
to look around but I didn't find any obvious way
to figure this info out.
Not a simple one. You might factor out the code for that in
write_unqualified_id into a separate function.
Jason
a function ending in
something other than "operator+"
If you're specifically looking for operator+, you can compare the name
to ansi_opname[PLUS_EXPR].
Jason
ement with no value, in function returning
‘int’ [-fpermissive]
So what do we gain from not emitting that warning by default there?
If we already give an error, we don't want to give a redundant warning.
I'm confused about what you're asking here.
Jason
cause we don't want people to
use them. I don't remember why that was, and system.h doesn't give a
rationale, so I'm not sure if actual uses in the C++ library are
problematic.
Jason.
to detect).
Jason
On 12/05/2013 10:59 AM, Oleg Endo wrote:
On Thu, 2013-12-05 at 10:45 -0500, Jason Merrill wrote:
A simple workaround would be to disable poisoning of malloc/realloc on
OS X (or when the build machine uses libc++, if that's easy to detect).
Whether libc++ uses malloc/realloc/free in
information for discarded functions is not
removed, and this could cause the debugger to get confused.
I did a bunch of work on doing this for COMDAT functions, but never
finished it. You can find my WIP in the jason/comdat-debug branch in
git. Want to integrate that with your work?
Before
ren't interesting to aliasing
either, so you should be OK just looking at field types.
Jason
s?
Right. The TYPE_SIZE of an empty class is still 1, but a base of such a
type doesn't get a FIELD_DECL.
Jason
appropriately on the TYPE_DECL
of a named type.
Jason
thought the linker always resolved such references to 0, and I think
that is what we want.
When discussed on IRC recently Jason preferred to move the DW_TAG_subprogram
describing a comdat function to a comdat .debug_info DW_TAG_partial_unit
and just reference all DIEs that need to be referenced from
e). Readelf and friends will need
to be taught how to find the right auxiliary debug sections, though --
they currently have a built-in assumption that there's only one of
each.
Good to know.
Jason
On 05/25/2012 11:37 AM, Joseph S. Myers wrote:
and it should be possible to eliminate the __need_* special cases
for some system headers by having more, smaller headers set up to define
individual types.
I was thinking the same thing.
Jason
On 06/04/2012 10:47 AM, Richard Guenther wrote:
On Mon, Jun 4, 2012 at 4:39 PM, Steven Bosscher wrote:
Jason, is this flag something that we could deprecate for GCC 4.7 and remove?
The docs say the flag is not useful these days as BSS is widely available.
Right. So yes, go ahead.
Jason
On 06/04/2012 04:04 PM, David Edelsohn wrote:
Is this feature necessary for non-ELF file formats, such as AIX XCOFF?
It's not necessary for XCOFF. I think it was only useful for a.out,
which doesn't support .bss.
Jason
On 06/04/2012 04:54 PM, Eric Botcazou wrote:
It's not necessary for XCOFF. I think it was only useful for a.out,
which doesn't support .bss.
No, the 2004 change wasn't for an a.out target, but most probably Mach-O.
Hmm, Mach-O does have BSS.
Jason
-only.
Jason
does. That change should not have gone into 4.7 without having a
plan to deal with the consequences. I thought we weren't going to mess
with ABI-breaking changes like this yet...
Jason
IBCXX_4
version, and any functions that deal with Wrap would be marked with that
version, and so on.
I'm not familiar enough with the intricacies of ELF versioning to be
confident that this would work; is anyone else? In particular I'm not
sure how the interaction of versioned and non-versioned code will work.
Jason
On 07/03/2012 08:08 AM, Michael Matz wrote:
Hi,
On Mon, 2 Jul 2012, Jeff Law wrote:
On 07/02/2012 11:53 AM, Paolo Carlini wrote:
I also want to mention (I don't think somebody did already in the
thread) that at some point, with Jason too, we discussed the idea of
adding to each bin
gh for 4.8 that we can drop that claim.
Jason
ace. This
is a bug that we're working on fixing.
Jason
would only affect
classes that derive from std::time_get in a multiple inheritance
context. But to be safe we could bump the time_get ABI as well as the
others.
Jason
On 07/03/2012 03:18 PM, Jason Merrill wrote:
It seems that ELF symbol versioning could be useful for this purpose. If
we were to extend the visibility attribute to also handle symbol
versions, that could handle a lot of issues. If Wrap uses the GLIBCXX_4
version of string, then Wrap would also
ere would be no need to repeat a suffix
from something that is itself mangled, such as a function argument type
or a template argument, but we would need to propagate a suffix from the
return type of a (non-template) function or the type of a variable as
well as from member/base types in a class.
Jason
move it in 4.9.
Jason
Does anyone have experience with Patchwork? It sounds like it works
with a mailing list with less requirement for special markup than
dannyb's tracker had.
Jason
On 09/26/2012 06:27 PM, Ian Lance Taylor wrote:
I propose that Cary Coutant become an additional
DWARF maintainer, along with Jason.
That makes sense to me.
Jason
cseside.
Does this make sense? Anyone more familiar with this area of the code
want to implement it for me? :}
Jason
On 10/03/2012 07:06 PM, Joseph S. Myers wrote:
On Wed, 3 Oct 2012, Jason Merrill wrote:
My implementation of dynamic initialization of TLS variables as mandated by
the C++11 and OpenMP standards uses this idiom implicitly, so I'd really like
to be able to optimize away multiple calls.
On 10/04/2012 08:45 AM, Jakub Jelinek wrote:
On Thu, Oct 04, 2012 at 10:42:59AM +0200, Richard Guenther wrote:
On Wed, Oct 3, 2012 at 9:00 PM, Jason Merrill wrote:
If the result is not needed, are we allowed to remove a call to this
function?
No. Unless you know the same function has been
On 10/04/2012 08:59 AM, Jakub Jelinek wrote:> On Thu, Oct 04, 2012 at
08:56:03AM -0400, Jason Merrill wrote:
> Sure, but I thought you want to inline the wrapper function as soon as
> possible. Or do you want to keep it as some kind of builtin that gets
> expanded during expansion
et is never cleared; it is the mechanism by which only the first
call has side effects.
init_count is a normal user variable.
Jason
e desirable for
user-written singleton functions, though.
Jason
301 - 400 of 587 matches
Mail list logo
