I committed this as obvious. The changelog says it all.
Thanks,
Andrew
2014-06-28 Andrew Pinski
* lto.c (lto_read_decls): Fix comment in comment.
Index: lto.c
===
--- lto.c (revision 212118)
+++ lto.c (working copy)
BTW, if I enable MAKE_DECL_ONE_ONLY for XCOFF, the endless loop does
not occur, so it clearly has some effect on AIX. Maybe it can
function well-enough on AIX.
- David
> Minor comments below, ok with those changes.
Thanks!
This is version of patch I commited after additional testing on building of
some bigger apps with LTO. The main change (in addition to those requested) is
that I moved the fixups into lto_copy_fields_not_streamed and added loop before
SCC unif
Ouch; it looks like my last attempt to reply to this missed gdb-patches@
due to a gmane accident?
Samuel Bronson writes:
> Tom Tromey writes:
>>> "Samuel" == Samuel Bronson writes:
>>
>> Samuel> [Am I really supposed to CC this to gcc@ like binutils/MAINTAINERS
>> Samuel> says I should?]
>
...and improve wording and markup a bit.
Applied.
Gerald
Index: bugs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/index.html,v
retrieving revision 1.113
diff -u -r1.113 index.html
--- bugs/index.html 28 Jun 2014 07:45:0
Jason,
this is another case cought by the type variant checking.
build_ptrmemfunc_type,
for qualified type, first calls itself recursively to produce member pointer
type
for unqalified variant.
Subsequentely it produces the member pointer from scratch - I believe it is
because
the field decl r
The attached patch is obvious and simple. I will commit to trunk soon.
There are two things obvious about this.
1) Using the wrong function for wide characters.
2) No one must be using this feature of Fortran since the bug exists at least
back to 4.5
;)
Regression tested on x86-64-linux-gnu.
On Sat, 28 Jun 2014, Ulrich Drepper wrote:
On Sat, Jun 28, 2014 at 6:42 AM, Marc Glisse wrote:
Ping,
nobody has an opinion on this? Or some explanation why I am mistaken to
believe that #pragma target makes it safer now?
It would enable a number of optimizations, like constant propagation, F
Remove a couple of links. Make a couple of links relative.
Consistently use bug tracker to refer to our Bugzilla system.
As a side effect, this further reduces the number of http links
to gcc.gnu.org.
Applied.
Gerald
Index: gcc-3.3/changes.html
Hi,
this patch fixes another problem where we manage to produce a variant of
variadic array that has different TYPE_SIZE (but an equivalent expression).
This happens because remap_type_1 blindly copies all expressions referred by
variadic type while for variants it may just reuse ones it earlier co
Hello,
we currently drop clobbers on variables whose address is not taken
anymore. However, rewrite_stmt has code to replace them with an SSA_NAME
with a default definition (an uninitialized variable), and I believe
rewrite_update_stmt should do the same. This allows us to warn sometimes
(see
On Thu, 12 Jun 2014, Richard Biener wrote:
> It seems the https transition broke refering to permanently moved
> URL gcc-3.0/gcc-3.0.html (I get a certificate error or some such),
> breaking gennews and thus gcc_release. Fixed like below which
> makes gennews succeed.
>
> Committed to the 4.7 bra
Please disregard previous email "Re: [Bug c++/60249] [c++11] Compiler
goes into semi-infinite loop with wrong usage of user defined string
literals"
A new patch with tweaked testcase is attached. Sorry for the noise.
I finally fixed these weird user-defined string literal bugs.
I was messing
Hi,
this issue manifests itself as an ICE on the gcc_assert toward the end
of start_decl:
if (VAR_P (decl)
&& DECL_NAMESPACE_SCOPE_P (decl) && !TREE_PUBLIC (decl) &&
!was_public
&& !DECL_THIS_STATIC (decl) && !DECL_ARTIFICIAL (decl))
{
/* This is a const variable with
Applied.
Richi, Jakub, I noticed that you seem to have stopped including those
with GCC 4.7 and later. Any particular reason? It appears useful to
me.
Gerald
Index: gcc-3.3/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-
Hi,
this patch fixes similar bug as in ipa-devirt. objc_xref_basetypes is used when
building obj-C++ structure. The structure always contains self-reference that
builds type variant early. The variant's binfo is one assigned by
C++ FE's version of xref_basetypes, while the main variant gets over
On 06/26/14 02:18, Rainer Orth wrote:
Ok for mainline?
Could you please reformat the c_fix_arg's and test-text to be "here strings" a
la:
c_fix_arg = <<- _EOS_
#undef signbit
#define signbit(x) (sizeof(x) == sizeof(float) \
\ ? __buil
On Jun 28, 2014, at 3:31 AM, Ulrich Weigand wrote:
> Mike Stump wrote:
>
>> (rs6000_aggregate_candidate): Use wide-int interfaces.
> [snip]
>> -/* Can't handle incomplete types. */
>> -if (!COMPLETE_TYPE_P (type))
>> - return -1;
>> +/* Can't handle incomplete types nor siz
Hi,
this patch does similar change to ipa-prop as I did to ipa-devirt; it makes
sure that
all the types in jump functions are main variants that reduces diversity in LTO
streaming
and makes us less likely to hit incomplete types.
It also makes sure that the type change detection works on main va
Hi,
this is another bug noticed. Here ipa-devirt attempts to merge binfos of two
representations
of the same ODR type, but forgets about variants.
I also noticed that using variant instead of the type may end up in incomplete
type and/or
we may waste polymorphic call target cache by duplicated
Hi,
This is first bug noticed by the type consistency checks I added.
gcov_info_type is a structure that contains function pointer to itself. While
building it we first build a structure w/o size and fields, then we build a
function type that produces a qualified variant of the structure (not sur
REQUEST FOR HELP: It would be great if one of the Java experts
could advise which further entries to remove or adjust. I volunteer
to make the actual changes, if that helps.
Now to this patch: Working on the web pages in general, I noticed a
number of obsolete FAQ entries in our Java FAQ. Som
On Sat, Jun 28, 2014 at 2:48 AM, Jonathan Wakely wrote:
> I wonder if it would be better to use a sorted
> vector> instead of a map, for improved
> memory footprint and runtime speed, but that can be changed later.
In this case, we keep inserting (__m[__u] = __id) and looking up
(__m.count()) the
This patch restores C++98 as the default language in this branch and
disables -fconcepts by default. Using -std=c++1z will enable
-fconcepts.
I wanted to give an error if -fconcepts is used with dialect <= cxx11,
but I didn't find the right place to put the check.
This also adds a new format spec
On Fri, 20 Jun 2014, Marek Polacek wrote:
+@item -fsanitize=bounds
+@opindex fsanitize=bounds
+
+This option enables instrumentation of array bounds. Various out of bounds
+accesses are detected. Flexible array members are not instrumented, as well
+as initializers of variables with static storag
On Sat, 28 Jun 2014, Paolo Carlini wrote:
for now I reverted this. Things get too complicated when we have to
conditionally export some symbols depending on the target (see
libstdc++/61536).
A single extra symbol (for the unusual -O0 compilation) is better than 200
before the patch though. I
Hi,
On 06/08/2014 06:02 PM, Paolo Carlini wrote:
Hi,
as discussed, tested x86_64-linux multilib, committed.
for now I reverted this. Things get too complicated when we have to
conditionally export some symbols depending on the target (see
libstdc++/61536).
Thanks,
Paolo.
On Sat, Jun 28, 2014 at 01:29:47PM +0200, Gerald Pfeifer wrote:
> On Fri, 27 Jun 2014, Jakub Jelinek wrote:
> > This patch implements sanitization for nonnull and returns_nonnull
> > attributes.
>
> No documentation patch?
I'll add it soon.
> Also, should this be documented in gcc-4.10/changes.h
ping*2
> ping
>
> To reinforce the message in my earlier email: we can fine-tune the list of
> allowed characters in identifiers later, but I’d like to get this patch in
> already (so it gets large exposure before the 4.10 release).
>
> FX
>
>
>
>> Binding label can be any initialisation e
After merging from trunk this morning, I discovered that
DECL_SIZE_UNIT is now being used to store lists of specializations. I
had been using that to store template constraints. Oops.
This patch moves constraints outside the usual tree structures into an
association maintained in a hash table. It
On Wed, 11 Jun 2014, Tobias Burnus wrote:
This patch converts some more files, but I think one should at
some point change all files.
I'm working on this now, alas not per file, but according to
groups of links and trying to clean up some aspects (by reducing
links and make them relative where
On Sat, Jun 28, 2014 at 6:42 AM, Marc Glisse wrote:
> Ping,
>
> nobody has an opinion on this? Or some explanation why I am mistaken to
> believe that #pragma target makes it safer now?
>
> It would enable a number of optimizations, like constant propagation, FMA
> contraction, etc. It would also
On 06/27/2014 05:39 PM, paolo.carlini at oracle dot com wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
--- Comment #5 from Paolo Carlini ---
Patch looks *great*. If it works, please send it to mailing list ASAP.
I think I finally got these weird user-defined string literal bugs.
"D
On Fri, 21 Mar 2014, Tobias Burnus wrote:
> Thanks for the suggestions - updated patch below.
Here are two small tweaks I just committed on top of this.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
Convert references to http://gcc.gnu.org/install/ and sub-pages to
https. Avoid some such links.
Committed.
Gerald
Index: faq.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v
retrieving revision 1.218
diff -u -r1.218 faq.html
On Fri, 27 Jun 2014, Jakub Jelinek wrote:
> This patch implements sanitization for nonnull and returns_nonnull
> attributes.
No documentation patch?
Also, should this be documented in gcc-4.10/changes.html?
> As GCC 4.9.0+ now aggressively optimizes based on these attributes and we've
> seen sev
Ping,
nobody has an opinion on this? Or some explanation why I am mistaken to
believe that #pragma target makes it safer now?
It would enable a number of optimizations, like constant propagation, FMA
contraction, etc. It would also allow us to remove several builtins.
On Sat, 17 May 2014, M
This is the right thing in general (considering mirror sites like
http://www.gnu.org/software/gcc/) and the fact that we know do not
need to convert these from http to https confirms that point.
It also shows that mass converting the entire wwwdocs tree in a
single step would not have been ideal.
Mike Stump wrote:
> (rs6000_aggregate_candidate): Use wide-int interfaces.
[snip]
> - /* Can't handle incomplete types. */
> - if (!COMPLETE_TYPE_P (type))
> - return -1;
> + /* Can't handle incomplete types nor sizes that are not
> +fixed. */
> + if (!COMPLET
On Mon, 23 Jun 2014, Tejas Belagod wrote:
Here is a patch that restructures neon builtins to use vector types based on
standard base types. We previously defined arm_neon.h's neon vector
types(int8x8_t) using gcc's front-end vector extensions. We now move away
from that and use types built int
Applied.
Gerald
Index: lists.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v
retrieving revision 1.108
diff -u -r1.108 lists.html
--- lists.html 27 Jun 2014 11:48:45 - 1.108
+++ lists.html 28 Jun 2014 08:05:33 -000
(oups, the message got stuck in my mailer, should have been sent a while
ago)
On Tue, 24 Jun 2014, DJ Delorie wrote:
Since the check for __STRICT_ANSI__ is removed, do we need to add
__extension__ in front of __GLIBCXX_TYPE_INT_N_0 to avoid warning with
-Wsystem-headers?
I copied the code fr
On 27/06/14 09:53 -0700, Tim Shen wrote:
On Fri, Jun 27, 2014 at 12:37 AM, Paolo Carlini
wrote:
The actual patch is missing.. ;)
Sigh...every time. Sorry.
PS: sorry for being distracted by other issues: what happened to the other
regex issue? I think we are simply going to apply, when ready
On 28/06/14 00:18 -0700, Tim Shen wrote:
diff --git a/libstdc++-v3/include/bits/regex_executor.h
b/libstdc++-v3/include/bits/regex_executor.h
index 1991c00..e02fa65 100644
--- a/libstdc++-v3/include/bits/regex_executor.h
+++ b/libstdc++-v3/include/bits/regex_executor.h
@@ -173,6 +173,8 @@ _GLIBC
On Tue, Jun 10, 2014 at 1:56 PM, Tim Shen wrote:
> On Tue, Jun 10, 2014 at 9:54 AM, Jonathan Wakely wrote:
>> I'm sure this is because I still don't understand all the regex code,
>> but doesn't this change mean that for an "extended" mode regex with
>> backrefs, the user could define _GLIBCXX_RE
45 matches
Mail list logo
