Hi,
A colleague noticed that we were not vectorizing loops that had end of
loop computations that were MIN type operations that weren't expressed
in the form of a typical min operation. A transform from (i x )
( i y) to ( i min (x, y)) is only something that we should do in
these situations
With some trepidation, because I suspect I'm missing the point :-)
Hans-Peter Nilsson hans-peter.nils...@axis.com writes:
Other target-patches exposed this for me.
I have on the 4.7-branch an insn:
(jump_insn 245 277 246 (set (pc)
(label_ref:SI 312)) whatever.c:511 -1
(nil)
-
Installed now, after an exchange with Igor and monitoring the mirror
for ten days.
Thanks, Igor!
Gerald
On Mon, 9 Apr 2012, Gerald Pfeifer wrote:
I was just going to add your server by means of the patch below,
alas all attempts to rach the server time out. What's going on?
Gerald
Hi,
I generate builtin function directly in the middle end and and expand
the builtin function in the x86 backend to certain set of
instructions.
I've defined x86 builtin functions in the gcc backend like this:
{ OPTION_MASK_ISA_TSTAR | OPTION_MASK_ISA_64BIT,
CODE_FOR_tstar_create,
Hello.
During the GCC 2.7.2/2.8.1 timeframe I sent emails to this list (or
some similar list) with patches. I have found evidence of the
patches being applied:
http://hg.sourceforge.jp/view/cbc/GCC/file/ec4cbc2ac877/gcc/FSFChangeLog
527 Sun Oct 4 08:37:36 1998 Paul Edwards a...@matra.com.au
From: Richard Sandiford rdsandif...@googlemail.com
Date: Sun, 22 Apr 2012 10:47:24 +0200
With some trepidation, because I suspect I'm missing the point :-)
Maybe but maybe not. Below it seems my observation was
misdiagnosed, and this is just a minor bug.
Hans-Peter Nilsson
Feng LI nemoking...@gmail.com writes:
I generate builtin function directly in the middle end and and expand
the builtin function in the x86 backend to certain set of
instructions.
I've defined x86 builtin functions in the gcc backend like this:
{ OPTION_MASK_ISA_TSTAR |
Paul Edwards mutazi...@gmail.com writes:
During the GCC 2.7.2/2.8.1 timeframe I sent emails to this list (or
some similar list) with patches. I have found evidence of the
patches being applied:
http://hg.sourceforge.jp/view/cbc/GCC/file/ec4cbc2ac877/gcc/FSFChangeLog
527 Sun Oct 4 08:37:36
Hi Ian,
2012/4/22 Ian Lance Taylor i...@google.com:
Feng LI nemoking...@gmail.com writes:
I generate builtin function directly in the middle end and and expand
the builtin function in the x86 backend to certain set of
instructions.
I've defined x86 builtin functions in the gcc backend like
Snapshot gcc-4.8-20120422 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120422/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #4 from Ivan Godard igodard at pacbell dot net 2012-04-22
06:08:28 UTC ---
Looking a little further at this, I don't think we can use init_array at all,
even if it ran in reverse order.
Consider TUs in a .a library, where some of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53069
Bug #: 53069
Summary: expected warnings are not given
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53069
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-22
07:19:29 UTC ---
Really you should not be dependent on the order since that has even been
defined. Yes you would think it would be defined but it was never a guarantee.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #6 from Ivan Godard igodard at pacbell dot net 2012-04-22
07:46:20 UTC ---
Yes, but. Order is not defined, but order dependencies are inescapable in C++
which has a tendency to invoke constructors where you least expect them - when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
Pawel Sikora pluto at agmk dot net changed:
What|Removed |Added
CC||pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
Ivan Godard igodard at pacbell dot net changed:
What|Removed |Added
CC||igodard at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52702
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52942
--- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22
08:08:05 UTC ---
*** Bug 53067 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059
--- Comment #6 from Evgeny Ratnikov ratnikov.ev at ya dot ru 2012-04-22
08:47:07 UTC ---
(In reply to comment #2)
Why do you think this is a bug?
The C++ 2011 standard requires that std::list::size() is O(1) so a new member
variable is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53070
Bug #: 53070
Summary: ICE: in execute_cse_reciprocals, at
tree-ssa-math-opts.c:513 with -O -ffast-math
-ftree-loop-if-convert -fno-tree-loop-im
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53071
Bug #: 53071
Summary: Wrong instruction replacement when compiling for xop
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53071
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #19 from Marc Glisse marc.glisse at normalesup dot org 2012-04-22
10:31:33 UTC ---
Created attachment 27217
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27217
shuffle
With this patch, g++ passes the few __builtin_shuffle tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46886
--- Comment #14 from razya at gcc dot gnu.org 2012-04-22 10:36:18 UTC ---
Author: razya
Date: Sun Apr 22 10:36:13 2012
New Revision: 186667
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186667
Log:
2012-04-20 Razya Ladelsky
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-22
11:38:36 UTC ---
(In reply to comment #6)
problem is that after such change my application (-std=98) linked with
libraries (-std=0x) causes corrupted stack.
You can't do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
--- Comment #20 from Uros Bizjak ubizjak at gmail dot com 2012-04-22 12:42:07
UTC ---
(In reply to comment #19)
int test (int a, int b)
{
int lt = a + b 0;
int eq = a + b == 0;
if (lt)
return 1;
return eq;
}
Actually, here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
--- Comment #21 from Uros Bizjak ubizjak at gmail dot com 2012-04-22 12:45:17
UTC ---
(In reply to comment #17)
The only one which is not fixed is comment #4
This testcase is fixed with patch at [1].
[1]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53058
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||jakub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #20 from Marc Glisse marc.glisse at normalesup dot org 2012-04-22
13:21:14 UTC ---
(In reply to comment #19)
Created attachment 27217 [details]
shuffle
Doesn't work with -std=c++11, which requires:
--- semantics.c(revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53027
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-22
14:14:21 UTC ---
Author: redi
Date: Sun Apr 22 14:14:15 2012
New Revision: 186671
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186671
Log:
PR libstdc++/53027
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53027
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52910
Agner Fog agner at agner dot org changed:
What|Removed |Added
CC||agner at agner dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-22
14:56:28 UTC ---
(In reply to comment #19)
With this patch, g++ passes the few __builtin_shuffle tests I tried, and
generates generic code for non-constant indexes and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #22 from Marc Glisse marc.glisse at normalesup dot org 2012-04-22
15:09:23 UTC ---
(In reply to comment #20)
And then I still need to write a cxx_eval_vec_perm function so the result of
__builtin_shuffle can be constexpr. I haven't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383
Thorsten Glaser tg at mirbsd dot org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22
16:10:38 UTC ---
I'm right now rebuilding both mainline and branch, because yesterday both
worked and I don't think we changed anything in this area. What the heck it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53072
Bug #: 53072
Summary: automatically set Init() only if option was not set in
some other way
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #97 from Ian Lance Taylor ian at airs dot com 2012-04-22 17:03:24
UTC ---
One option you have is to configure gcc with --disable-initfini-array.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073
Bug #: 53073
Summary: [4.8 Regression] 464.h264ref in SPEC CPU 2006
miscompiled
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53051
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-22
17:28:39 UTC ---
Author: burnus
Date: Sun Apr 22 17:28:34 2012
New Revision: 186675
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186675
Log:
2012-04-22 Tobias Burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53051
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
--- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2012-04-22 17:38:07 UTC ---
Author: paolo
Date: Sun Apr 22 17:37:57 2012
New Revision: 186676
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186676
Log:
2012-04-22 Paolo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
--- Comment #6 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2012-04-22 17:38:18 UTC ---
Author: paolo
Date: Sun Apr 22 17:38:11 2012
New Revision: 186677
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186677
Log:
2012-04-22 Paolo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #98 from Ivan Godard igodard at pacbell dot net 2012-04-22
17:44:24 UTC ---
It's OK if you reverse the default order - make it sideways if it gets a faster
Firefox. We can cope.
It's OK is you dump ctors for init_array if it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #99 from Jan Hubicka hubicka at ucw dot cz 2012-04-22 18:33:44
UTC ---
OK to re-open this ticket?
If ctor order was/is controllable via linker script, it seems that you need
similar feature for init arrays. In that case it is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53074
Bug #: 53074
Summary: insn-recog.c:recog calls predicates known to be false
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #100 from Paolo Carlini paolo.carlini at oracle dot com
2012-04-22 18:43:18 UTC ---
As as side, Sunday-type, observation, we don't normally use the work 'ticket'
here (if only because no money is involved, at least, not in the open ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059
--- Comment #8 from Evgeny Ratnikov ratnikov.ev at ya dot ru 2012-04-22
19:11:22 UTC ---
(In reply to comment #7)
(In reply to comment #6)
problem is that after such change my application (-std=98) linked with
libraries (-std=0x) causes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
--- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-22
19:17:51 UTC ---
Author: manu
Date: Sun Apr 22 19:17:47 2012
New Revision: 186681
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186681
Log:
2012-04-22 Manuel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059
--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-22
19:18:13 UTC ---
That last situation is really totally unsupported and never was. By the way, I
don't know if you noticed already, but it doesn't work for many, many,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #101 from Ivan Godard igodard at pacbell dot net 2012-04-22
19:35:08 UTC ---
Well, it's easy to say that it's the other guy's problem, but it isn't. You are
assuming that the linker is always gnu ld; for big shops with multi-platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53075
Bug #: 53075
Summary: -Werror=pedantic should be equivalent to
-pedantic-errors
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37187
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53076
Bug #: 53076
Summary: [4.8 Regression]: gcc.dg/torture/builtin-explog-1.c,
gcc.dg/torture/builtin-power-1.c at -O0 soft-float
newlib
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077
Bug #: 53077
Summary: suggestion to add the .f extension to the list of file
extensions that trigger enabling of the preprocessor
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077
--- Comment #1 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-04-22
20:35:49 UTC ---
The gfortran-mp-4.6 vs. gfortran difference in the code above is not relevant
to the issue.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #102 from Ian Lance Taylor ian at airs dot com 2012-04-22
21:16:14 UTC ---
To be clear, nothing has changed in collect2. The only thing that has changed
is that data that was being emitted in the .ctors section is now being emitted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077
--- Comment #2 from Sylwester Arabas slayoo at staszic dot waw.pl 2012-04-22
21:36:33 UTC ---
Hmm... apparently the PGI compiler uses the same rule for enabling preprocessor
with .f and .F extensions. Then, if there's some important reason behind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #103 from Ivan Godard igodard at pacbell dot net 2012-04-22
21:52:40 UTC ---
I may be just displaying my ignorance, but my understanding is that order under
init_array is governed by order of pointers within the array itself, and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #104 from Ian Lance Taylor ian at airs dot com 2012-04-22
22:26:50 UTC ---
I'm not sure what you mean. Each object file will have a .init_array section.
The linker will assemble those sections in the usual manner.
The order of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53078
Bug #: 53078
Summary: [C++11] Wrong diagnostic no return statement in
function returning non-void on
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53065
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53079
Bug #: 53079
Summary: Unwanted optimization occurs on function with the same
name as a math.h function without including math.h nor
linking with libm
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53078
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-23
00:21:43 UTC ---
Are you *really* sure you are using current 4.8? I get:
paolo@poldo4:~/Work g++ -std=c++11 -Wall -Wextra -Werror -pedantic 53078.C
53078.C: In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23
01:17:16 UTC ---
Why can't you just pass the -cpp option to gfortran if you want to enable the
preprocessor?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53079
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23
01:19:48 UTC ---
This is expected. If you don't want floor to be considered a builtin, then use
-fno-builtin-floor . The C standard even says the name is in the reversed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53076
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23
01:26:41 UTC ---
I saw this failure on non soft-float x86 too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53080
Bug #: 53080
Summary: std::array - std::get() and std::tuple_element is
nothing bounds check
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53076
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.8 Regression]: |[4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059
--- Comment #10 from Evgeny Ratnikov ratnikov.ev at ya dot ru 2012-04-23
02:47:37 UTC ---
Now it's clear. Thanks for replies.
.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53078
--- Comment #2 from M8R-gt1qwe at mailinator dot com 2012-04-23 03:58:52 UTC ---
Ooops. That will teach me to make sure I update before filing a bug :S I was
running 20120401. You can close this. It doesn't manifest on 20120422.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
Bug #: 53081
Summary: memcpy/memset loop recognition
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23
05:03:28 UTC ---
I thought there is already one part of graphite.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-23
05:07:30 UTC ---
I should mention I made one patch before based on the vectorizer code which did
detection of at least memset; it was while I was an intern at Apple. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #3 from davidxl xinliangli at gmail dot com 2012-04-23 05:34:24
UTC ---
(In reply to comment #2)
I should mention I made one patch before based on the vectorizer code which
did
detection of at least memset; it was while I was an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #4 from davidxl xinliangli at gmail dot com 2012-04-23 05:34:55
UTC ---
(In reply to comment #2)
I should mention I made one patch before based on the vectorizer code which
did
detection of at least memset; it was while I was an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53082
Bug #: 53082
Summary: local malloc/free optimization
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Installed now, after an exchange with Igor and monitoring the mirror
for ten days.
Thanks, Igor!
Gerald
On Mon, 9 Apr 2012, Gerald Pfeifer wrote:
I was just going to add your server by means of the patch below,
alas all attempts to rach the server time out. What's going on?
Gerald
On 16 April 2012 21:28, Jonathan Wakely wrote:
I have a patch to add the checks to debug/forward_list
And here it is, only checking in debug mode because noone objected to
that suggestion.
* include/debug/forward_list (forward_list::splice_after): Check
allocators are equal.
* include/bits/ptr_traits.h (pointer_traits::rebind): Make public.
* testsuite/20_util/pointer_traits/requirements/typedefs.cc: Check
rebind works.
Tested x86_64linux, committed to trunk and will commit to 4.7 soon.
commit 6141cdceb14025ef258b8809301558f5962bf7ab
Author:
The allocator_traits wrapper is missing difference_type, noticed while
making vstring allocator-aware.
* include/ext/alloc_traits.h (__alloc_traits::difference_type):
Define.
Tested x86_64-linux, committed to trunk.
commit 7a3e74660df7df20bebb7676cd9142841637ba40
Author: Jonathan
Thomas: Please write branch changes not in libgfortran/ChangeLog but in
libgfortran/ChangeLog.fortran-dev; that avoids merge problems when
updating from the trunk.
The branch (rev. 186674) now matches the trunk (Rev. 185178-186672).
Unfortunately, there are still about a dozen failures.
As described by Linus here:
http://lkml.indiana.edu/hypermail/linux/kernel/0611.3/1020.html
Wshadow warns whenever any declaration shadows a global function
declaration. This is almost always noise, since most (always?) of the
time one cannot mistakenly replace a function by another variable. The
On Fri, Apr 20, 2012 at 12:18, Tobias Burnus bur...@net-b.de wrote:
Dear all,
some compilers support using q to indicate quad precision, e.g. 4.0q0.
Since GCC 4.7, gfortran supports this vendor extension in the source code.
However, READing the floating-point number 4.0q0 was not supported.
On Thu, Apr 19, 2012 at 5:47 AM, Richard Guenther rguent...@suse.de wrote:
This fixes PR53031 and reverts back to using the number of latch
iterations in VRP when computing ranges for induction variables.
Now after ira_allocno_object_iter_cond is fixed this no longer
breaks bootstrap.
On Sat, Apr 21, 2012 at 3:43 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Apr 19, 2012 at 5:47 AM, Richard Guenther rguent...@suse.de wrote:
This fixes PR53031 and reverts back to using the number of latch
iterations in VRP when computing ranges for induction variables.
Now after
On Sun, Apr 22, 2012 at 10:14 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Apr 19, 2012 at 5:47 AM, Richard Guenther rguent...@suse.de wrote:
This fixes PR53031 and reverts back to using the number of latch
iterations in VRP when computing ranges for induction variables.
Now after
On Sun, Apr 22, 2012 at 10:50 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
This patch makes Wpedantic the canonical form of -pedantic. This makes
-Wno-pedantic, -Werror=pedantic, #pragma diagnostics and other parts
of the diagnostic machinery that expect warning options to start with
On Sun, Apr 22, 2012 at 11:00 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
As described by Linus here:
Interestingly, the C++ FE does not warn for this case, but it is not
very clear to me where this decision is taken.
C++'s type system does not make it very likely to get into the
Hi,
tested x86_64-linux, committed mainline and branch.
Thanks,
Paolo.
///
2012-04-22 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/53067
* include/bits/hashtable_policy.h: Change inheritances to public.
*
1 - 100 of 129 matches
Mail list logo
