Hello,
This mailing list is for the development of GCC, not for using it.
gcc-help might be more appropriate for this kind of question, although
it doesn't seem to be GCC related.
Please do not send any follow ups to gcc@gcc.gnu.org
On Fri, 2013-08-02 at 18:25 -0700, eric lin wrote:
I have
Hello, I follow your suggestion change from Macro to function, it improved a
little bit, but still not correct result
--
root@eric-laptop:/home/eric/fundamentalsofdatastructuresincpp/ch7# ./a.out
26 5 1 37 61 11 59 15 48 19
bal[1]= 5
bal[1]= 5
bal[1]= 5
bal[1]= 5
bal[1]= 5
Hi!
As I didn't know who to mail, I ask my question on this mailinglist.
Please apologize if that's the wrong place.
For an article about the history of GCC for the german Linux Magazin
(our sister publication is the Linux Pro Magazine) we are searching for
a GCC expert (especially someone
Please take this to the gcc-help mailing list, as requested.
On 3 August 2013 16:34, eric lin fs...@luxmail.com wrote:
Hello, I follow your suggestion change from Macro to function, it improved a
little bit, but still not correct result
--
On 07/18/2013 04:48 PM, Tom Tromey wrote:
There may be more missing dependencies. Please try out this branch if
you would. You can report bugs to me, just send the build log.
I've done a couple of builds, and had a browse through the patches on the
branch. It's looking pretty good to me. I
On Sat, Aug 3, 2013 at 4:11 PM, Richard Henderson r...@redhat.com wrote:
I hope we can merge this soon.
Seconded.
-- Gaby
Snapshot gcc-4.7-20130803 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20130803/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Mon, Jul 22, 2013 at 5:22 AM, Igor Zamyatin izamya...@gmail.com wrote:
Hi All!
Unfortunately now the compiler generates wrong code for i686 target
when options -O3 and -flto are used. It started more than a month ago
and reflected in PR57602.
Such combination of options could be quite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
--- Comment #2 from Uroš Bizjak ubizjak at gmail dot com ---
You can add -mtls-dialect=gnu2 to -fpic and -mcmodel=large.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047
fabien at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58070
Bug ID: 58070
Summary: gcc.c-torture: useless check -O3
-fomit-frame-pointer
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53976
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #2)
Interestingly, the following function shows some improved behavior (notice
the removed volatile mem store):
int test_2_1 (int* a, int b, int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #27 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #24)
Created attachment 30594 [details]
Proposed patch
I think it would be safe to put my initial test case
under
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58070
--- Comment #1 from Andreas Schwab sch...@linux-m68k.org ---
This is target dependent.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #187 from Jan Hubicka hubicka at gcc dot gnu.org ---
WPA time report
Execution times (seconds)
phase setup : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
1398 kB ( 0%) ggc
phase opt and generate : 80.79 (13%)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58070
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Andreas Schwab from comment #1)
This is target dependent.
OK, my target is --target=arm-eabi
What exactly is target dependent?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58070
--- Comment #3 from Andreas Schwab sch...@linux-m68k.org ---
The default state of -fomit-frame-pointer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58059
--- Comment #3 from Mikael Pettersson mikpe at it dot uu.se ---
The non-preprocessed test case crashes g++ 4.7, 4.8, and 4.9 for me on
x86_64-linux.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061
--- Comment #1 from Mikael Pettersson mikpe at it dot uu.se ---
This is clearly a duplicate of PR57848. Then there is PR57897 which crashes
with a different error message but still on #pragma target and mingw, I believe
that one is at least
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58064
--- Comment #1 from Mikael Pettersson mikpe at it dot uu.se ---
init2.c:37: MPFR assertion failed: (64 - 0) == ((64 - 0)/8) * 8
sizeof(mp_limb_t) == ((64 - 0)/8)
seems your mpfr library is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58071
Bug ID: 58071
Summary: Premature instantiation of default argument
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58071
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
We may have a Dup of this. I'll check later today if nobody beats me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58070
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com ---
You should ;) Seriously, when committing a patch I think that it's a good
practice to double check it on the duplicates, even if everything goes well
consider adding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
--- Comment #9 from Bill Schmidt wschmidt at gcc dot gnu.org ---
I missed a couple of candidate replacements in the previous fix; these are
fixed in r201466.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58072
Bug ID: 58072
Summary: [C++11] Error messages involving user-defined literals
are poor (refer to tokens)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58072
--- Comment #1 from Ed Smith-Rowland 3dw4rd at verizon dot net ---
Created attachment 30604
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30604action=edit
Patch c_parse_error to catch and describe user-defined literal tokens
explicitly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58073
Bug ID: 58073
Summary: Suboptimal optimisation of ((x 0x70) == 0x00 (x
0x70) == 0x10 (x 0x70) == 0x20) on x86_64
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58073
--- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com ---
Interestingly, the suboptimality shifts if the 'shift' value in the demo
program is changed to 0:
Going through the cases individually::
(1) return (mask(d) == (0x0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58072
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074
Bug ID: 58074
Summary: [C++11] __is_trivial intrinsic fails for deleted
members and for non-trivial copy-c'tors
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
... and the issue is one more level deeper, because __is_trivial just uses the
internal trivial_type_p. I mean, it should be pretty easy to construct
testcases not involving
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58046
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58062
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58027
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57138
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51239
--- Comment #6 from Jason Merrill jason at gcc dot gnu.org ---
Patch applied as r201469. Leaving suspended until the DR resolution is final.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
The standard streams are indeed special, being constructed once and never
destroyed, see libstdc++-v3/src/c++98/ios_init.cc. I suppose a minimal
reproducer could involve a file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53756
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||jason at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com ---
(In reply to Paolo Carlini from comment #2)
I suppose a minimal reproducer could involve a file scope static of some
sort...
I'm a bit confused by your reply, Paolo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Sorry, I didn't study it in sufficient detail. Anyway, no mysteries, this is
free software: libstdc++-v3/src/c++98/ios_init.cc etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com ---
Ah, in case isn't obvious already: it only happens when the I/O expression
has the ! operator in front.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #6 from Daniel Krügler daniel.kruegler at googlemail dot com ---
(In reply to Paolo Carlini from comment #5)
Ah, in case isn't obvious already: it only happens when the I/O expression
has the ! operator in front.
I suspected that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com ---
I'm not at all sure! But it happens with -O0 too, right?, thus at this point
the front-end seems more likely than the back-end, I would not change the
Component from c++ to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #8 from Daniel Krügler daniel.kruegler at googlemail dot com ---
(In reply to Paolo Carlini from comment #7)
But it happens with -O0 too, right?
Yes.
In any case we badly need a reduced testcase ;)
I agree. Unfortunately I'm on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com ---
Your help is always very appreciated, Daniel. Here we have plenty of work to do
anyway, if when you will back the bug will be unchanged, consider helping more.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979
--- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
The problem here is that float2 has alignment 8, although this is not it's
natural alignment (which would be 4).
This argument is passed by value to the routine operator-(float,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
David Abdurachmanov david.abdurachmanov at gmail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
David Abdurachmanov david.abdurachmanov at gmail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58075
Bug ID: 58075
Summary: Unable to build go on ia64-hp-hpux11.31
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061
--- Comment #2 from Whitequill Riclo whitequill at abstractions dot me ---
This is the first bug I have reported, so I didn't know where to look to see if
it has been reported before.
Also I can reproduce it over, and over again without fail.
I
On x86_64, when the expected size of memcpy/memset is known (e.g, with
FDO), libcall strategy is used with the size is 8192. This value is
hard coded, which makes it hard to do performance tuning. This patch
adds two new parameters to do that. Potential usage includes
per-application libcall
Hi Martin,
I have applied the patch on top of r201441 and I still get the warning for
gcc/testsuite/gfortran.dg/class_48.f90 with -m32 -O(2|s):
/opt/gcc/work/gcc/testsuite/gfortran.dg/class_48.f90: In function
'__final_test2_T.2136.constprop.0':
---
gcc/cp/lambda.c | 77 ++---
1 file changed, 57 insertions(+), 20 deletions(-)
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 98a7925..cf662bb 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -759,12 +759,9 @@
---
gcc/cp/cp-tree.h | 2 +-
gcc/cp/decl.c| 3 ++-
gcc/cp/lambda.c | 2 +-
gcc/cp/parser.c | 6 ++
gcc/cp/pt.c | 4 ++--
5 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 64ff4e3..17bb8b9 100644
--- a/gcc/cp/cp-tree.h
+++
---
gcc/cp/pt.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dea1ec0..6e209f8 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21317,8 +21317,15 @@ add_implicit_template_parms (size_t count, tree
parameters)
// Rewrite the
Hi Jason,
I've addressed your review comments and provided support for
conversion to function pointer for generic lambdas. I've sent the
patches as updates to the previous set. I'll wait for any further
comments before formalizing them into a cleaner set.
The changes now support the examples
On Thu, Aug 1, 2013 at 7:25 AM, Adam Butcher a...@jessamine.co.uk wrote:
---
gcc/cp/pt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a7baaba..99bc71b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1986,7 +1986,7 @@
On Thu, Aug 1, 2013 at 7:25 AM, Adam Butcher a...@jessamine.co.uk wrote:
---
gcc/cp/cp-tree.h | 2 +-
gcc/cp/decl.c| 3 ++-
gcc/cp/lambda.c | 2 +-
gcc/cp/parser.c | 6 ++
gcc/cp/pt.c | 4 ++--
5 files changed, 8 insertions(+), 9 deletions(-)
When submitting patches, you
On 03.08.2013 14:39, Gabriel Dos Reis wrote:
On Thu, Aug 1, 2013 at 7:25 AM, Adam Butcher a...@jessamine.co.uk
wrote:
---
gcc/cp/cp-tree.h | 2 +-
gcc/cp/decl.c| 3 ++-
gcc/cp/lambda.c | 2 +-
gcc/cp/parser.c | 6 ++
gcc/cp/pt.c | 4 ++--
5 files changed, 8 insertions(+), 9
On 03.08.2013 14:35, Gabriel Dos Reis wrote:
On Thu, Aug 1, 2013 at 7:25 AM, Adam Butcher a...@jessamine.co.uk
wrote:
---
gcc/cp/pt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a7baaba..99bc71b 100644
--- a/gcc/cp/pt.c
+++
In the fix for PR57993, I missed some cases where the candidate table
needed to be updated when a candidate statement in the table might
become stale. This corrects those issues. One of the missing cases
showed up in povray when compiling SPEC cpu2006.
Bootstrapped and tested on
On Sat, Aug 3, 2013 at 1:06 AM, Jan Hubicka hubi...@ucw.cz wrote:
On x86_64, when the expected size of memcpy/memset is known (e.g, with
FDO), libcall strategy is used with the size is 8192. This value is
hard coded, which makes it hard to do performance tuning. This patch
adds two new
Hi all,
the attached patch plugs a memory leak of the TRANSFER intrinsic,
which can occur when transferring to CHARACTER strings. For details
see the PR.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk/4.8/4.7?
Cheers,
Janus
2013-08-03 Janus Weil ja...@gcc.gnu.org
PR fortran/58058
On 08/01/2013 08:25 AM, Adam Butcher wrote:
+= DECL_TEMPLATE_INFO (callop)
+ DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (callop)) == callop;
An expression broken across lines should be parenthesized.
And let's move the building of 'call' for the non-template case up to be
with the
On 08/01/2013 02:06 PM, Marek Polacek wrote:
SAVE_EXPRs are evaluated only once;
in that COMPOUND_EXPR, when we first encounter SAVE_EXPR x and
call get_initialized_tmp_var, we get temporary value for it, x.2.
Then, in the second part of the COMPOUND_EXPR, we meet SAVE_EXPR x
again, but it
Hello world,
the rather self-explanatory patch implements the -Wzerotrip
option. The positive form is not really useful, because
the option is on by default (so the default behavior is
not changed).
The negative form of the option, -Wno-zerotrip, suppresses the
warning. I have also added
This patch introduced new C++ testsuite regressions.
FAIL: g++.dg/ipa/devirt-11.C -std=gnu++98 scan-ipa-dump-times inline
Discovered a virtual call to a known target 3
FAIL: g++.dg/ipa/devirt-11.C -std=gnu++98 scan-ipa-dump-times inline
and turned into root of the clone tree 1
FAIL:
On 08/02/2013 02:38 PM, David Malcolm wrote:
OK for trunk? (as part of patches 3-6)
Ok.
Hi Maintainers,
This patch adds macros to support gprof in Aarch64. The difference
from the previous patch is that the compiler, while generating
mcount routine for an instrumented function, also passes the return
address as argument.
The mcount routine in glibc will be modified as follows.
On 08/02/2013 02:43 PM, David Malcolm wrote:
gcc/
* Makefile.in (GTFILES): Add context.h.
* context.c (gcc::context::operator new): New.
(gcc::context::gt_ggc_mx): New.
(gcc::context::gt_pch_nx): New.
(gcc::context::gt_pch_nx): New.
* context.h
.. I don't know if at this Stage we are paying attention to these minor
details, but at least Patch 1 and 3 appear to have some overlong lines.
Thanks!
Paolo.
On 08/02/2013 02:48 PM, David Malcolm wrote:
+pass_manager::gt_ggc_mx ()
+{
+ ::gt_ggc_mx (all_passes);
+ ::gt_ggc_mx (all_small_ipa_passes);
+ ::gt_ggc_mx (all_lowering_passes);
+ ::gt_ggc_mx (all_regular_ipa_passes);
+ ::gt_ggc_mx (all_lto_gen_passes);
+ ::gt_ggc_mx
This is the first in a series of cleanup patches to the pretty printer
data structures and routines.
Tested on an x86_64-suse-linux.
Applied to trunk.
2013-08-03 Gabriel Dos Reis g...@integrable-solutions.net
* pretty-print.h (pp_underscore): New.
(pp_comma): Tidy.
*
Hi, GCC/i386 currently has about 73 boolean parameters/knobs (defined
in ix86_tune_features[], indexed by ix86_tune_indices) to perform
micro-arch specific performance tuning. However such settings are hard
coded (fixed with a given -mtune setting) and is very hard to do
performance experiment.
DR 1430 seems to be being resolved to prohibit passing a pack expansion
to a non-pack parameter of an alias template. I disagree with this
direction, but I'm going to go ahead and implement it for now.
The second patch implements DR 1286, which allows an alias template to
be equivalent to
On Sat, Aug 3, 2013 at 3:31 PM, Jason Merrill ja...@redhat.com wrote:
DR 1430 seems to be being resolved to prohibit passing a pack expansion to a
non-pack parameter of an alias template. I disagree with this direction,
but I'm going to go ahead and implement it for now.
I too disagree. Do
On Fri, Aug 2, 2013 at 9:33 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
If nobody has further comments over the next day or so, patch is Ok with me.
Committed. // http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00826.html
PS: I think it would be nice if from to time you could provide a rough
On 08/03/2013 06:43 PM, Gabriel Dos Reis wrote:
On Sat, Aug 3, 2013 at 3:31 PM, Jason Merrill ja...@redhat.com wrote:
DR 1430 seems to be being resolved to prohibit passing a pack expansion to a
non-pack parameter of an alias template. I disagree with this direction,
but I'm going to go ahead
Hi,
What's the format I should use? An email? Comments in the code? A PDF
document? Or?
All sorts of comments in the code are always welcome: blurbs at the beginning
of each file explaining the main design choices, then smaller comments
explaining tricky points, TODO or FIXME when
86 matches
Mail list logo
