On Saturday, October 20, 2012 7:50 AM, Chandler Carruth wrote:
[...snip...] Let me hypothesize a different interface:
This stays the same...
constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1,
q+1,
On Oct 19, 2012, at 10:51 PM, Richard Smith rich...@metafoo.co.uk wrote:
On Fri, Oct 19, 2012 at 10:50 PM, Chandler Carruth chandl...@google.com
wrote:
On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith rich...@metafoo.co.uk wrote:
[Crossposted to both GCC and Clang dev lists]
Hi,
One
On Fri, Oct 19, 2012 at 10:50 PM, Chandler Carruth chandl...@google.com wrote:
On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith rich...@metafoo.co.uk
wrote:
[Crossposted to both GCC and Clang dev lists]
Hi,
One issue facing library authors wanting to use C++11's constexpr feature
is that
Hello, I'm working with the BeagleBone and gcc-4.5.4 on Gentoo. If I
try to compile the 3.6 kernel with CONFIG_THUMB2_KERNEL, I get:
arch/arm/boot/compressed/head.S:127: Error: selected processor does
not support requested special purpose register -- `mrs r2,cpsr'
David got me past my first problem.
AIX 6.1 TL07 SP03, gcc 4.5.2 git repository on master. Last pull was
commit 43780738cd22a2fbea5fd7d8260a76e0c3121f43
Author: hubicka hubicka@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Sat Oct 20 14:19:12 2012 +
Here is the new error:
On Oct 19, 2012, at 23:27 , Andy Gibbs andyg1...@hotmail.co.uk wrote:
On Saturday, October 20, 2012 7:50 AM, Chandler Carruth wrote:
[...snip...] Let me hypothesize a different interface:
This stays the same...
constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
Snapshot gcc-4.7-20121020 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20121020/
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 Sat, Oct 20, 2012 at 12:53 AM, Chandler Carruth chandl...@google.com wrote:
On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith rich...@metafoo.co.uk wrote:
[Crossposted to both GCC and Clang dev lists]
Hi,
One issue facing library authors wanting to use C++11's constexpr feature is
that
On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose jordan_r...@apple.com wrote:
While throwing things out there, why not just optionally allow constexpr
functions to coexist with non-constexpr functions of the same name, like
inline and non-inline?
Or remove most of the restrictions on constexpr
On Sat, Oct 20, 2012 at 7:36 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose jordan_r...@apple.com wrote:
While throwing things out there, why not just optionally allow constexpr
functions to coexist with non-constexpr functions of the
On Sat, Oct 20, 2012 at 10:23 PM, Richard Smith rich...@metafoo.co.uk wrote:
Allow loops and the like in constexpr functions and be done with it. See my
comments on the C++ Extension Working Group when these (and related)
issues where brought up.
Yes, I completely agree, but I don't think
On Oct 20, 2012, at 20:23 , Richard Smith rich...@metafoo.co.uk wrote:
On Sat, Oct 20, 2012 at 7:36 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose jordan_r...@apple.com wrote:
While throwing things out there, why not just optionally
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54995
Bug #: 54995
Summary: Converting lambda to C-style functions when there is
template
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54963
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54994
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-20
06:55:45 UTC ---
*** Bug 54994 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54995
--- Comment #1 from niXman i.nixman at gmail dot com 2012-10-20 07:15:28 UTC
---
App crash:
http://liveworkspace.org/code/3d5e51c9059ea4f37ce2d0d23739d374
More detailed output.
source:
#include stdio.h
typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54996
Bug #: 54996
Summary: gcc with --target=avr fails to build
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54996
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54986
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Component|c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54995
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-20
08:31:12 UTC ---
May be duplicate of other known issues about lambdas vs templates.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54997
Bug #: 54997
Summary: -Wunused-function gives false warnings for procedures
passed as actual argument
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54997
--- Comment #1 from janus at gcc dot gnu.org 2012-10-20 08:58:19 UTC ---
(In reply to comment #0)
Obviously s3 is not being called directly, but it is passed to s2, so it's
certainly not unused.
Well, to be honest, 'dummy' is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54997
--- Comment #2 from janus at gcc dot gnu.org 2012-10-20 09:03:30 UTC ---
(In reply to comment #0)
subroutine s2(dummy)
procedure() :: dummy
end subroutine
Also an Unused dummy argument warning is missing here ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54963
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54983
--- Comment #4 from Bastian Hecht hechtb at gmail dot com 2012-10-20 10:30:28
UTC ---
Ok I see. Thanks for taking a look at this! I'll check if this is some
regression in the tree and either write a patch or post the issue on the ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #27 from Jan Hubicka hubicka at gcc dot gnu.org 2012-10-20
10:34:58 UTC ---
Thank you for testing. It seems that the patch works well for small benchmarks,
I will look into lapack/test_fpu slowdown.
There is problem that it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53145
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #28 from Dominique d'Humieres dominiq at lps dot ens.fr
2012-10-20 11:22:16 UTC ---
If I understand correctly the patch, the default value for
max-inline-min-speedup is 20. This could be over-agressive: for fatigue.f90 the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54989
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC|steven at gcc dot gnu.org |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #29 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-10-20
12:10:49 UTC ---
Another approach (not for the benchmarks) would be to
make inlining tunable by the user, e.g. support
!GCC$ ATTRIBUTES always_inline ::
System:
Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012;
root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
GCC build command: ./configure --enable-languages=c,c++
g++ --version
g++ (GCC) 4.8.0 20121020 (experimental)
Additional notes:
By either naming the union, or supplying a default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40989
--- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-10-20
14:17:14 UTC ---
Author: manu
Date: Sat Oct 20 14:17:08 2012
New Revision: 192635
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192635
Log:
2012-10-20 Manuel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063
--- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-10-20
14:17:14 UTC ---
Author: manu
Date: Sat Oct 20 14:17:08 2012
New Revision: 192635
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192635
Log:
2012-10-20 Manuel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54980
--- Comment #6 from Dmitry G. Dyachenko dimhen at gmail dot com 2012-10-20
14:28:28 UTC ---
192529 OK
192538 FAIL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31119
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31119
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-10-20 14:59:08 UTC ---
(In reply to comment #7)
Hi,
can someone fortran aware please double-check that the tests
* gfortran.dg/bounds_check_9.f90:
version 4.8.0 20121020 (experimental) [trunk revision 192631] (GCC)
[vocms123] ~/public/ctest/bugs48 $ c++ -msse3 -std=c++11 -c -O2 ice_mcp.ii
In file included from
/afs/cern.ch/cms/sw/ReleaseCandidates/slc5_amd64_gcc472/thu/6.1.LTO-thu-02/CMSSW_6_1_LTO_X_2012-10-18-0200/src/DataFormats/CLHEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844
vincenzo Innocente vincenzo.innocente at cern dot ch changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54999
vincenzo Innocente vincenzo.innocente at cern dot ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31119
--- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-10-20
15:43:13 UTC ---
can someone fortran aware please double-check that the tests
* gfortran.dg/bounds_check_9.f90: New test.
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54725
--- Comment #8 from Mike Frysinger vapier at gentoo dot org 2012-10-20
16:55:05 UTC ---
(In reply to comment #7)
that patch doesn't work as there is a typo in Make-lang.in. it needs to be:
CFLAGS-fortran/cpp.o +=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47389
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||mikpe at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54989
--- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-20
17:11:16 UTC ---
(In reply to comment #1)
The failure is caused by higher register pressure in the THEN branch of the
case, though I am not sure why the register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54989
--- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-20
17:39:45 UTC ---
(In reply to comment #1)
i can confirm that the proposed simplification of the test cases eliminates the
failures of hoist-register-pressure.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54855
--- Comment #6 from Marc Glisse glisse at gcc dot gnu.org 2012-10-20 17:43:44
UTC ---
Uros' reply at http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01327.html copied
here for convenience:
But, we _do_ have vec_merge pattern that describes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54989
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55001
Bug #: 55001
Summary: Handle VEC_COND_EXPR in tree-vect-generic.c
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54997
--- Comment #3 from janus at gcc dot gnu.org 2012-10-20 18:45:05 UTC ---
(In reply to comment #2)
Also an Unused dummy argument warning is missing here ...
This is fixed by the following patch:
Index: gcc/fortran/decl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55002
Bug #: 55002
Summary: trailing return type is rejected in function signature
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55002
--- Comment #1 from Leonid Volnitsky leonid at volnitsky dot com 2012-10-20
19:20:00 UTC ---
I've probably overcomplicated my example. Simpler test case:
--
int f(auto (*ff) - int (int) ) {
return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55002
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54315
--- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-10-20
21:00:26 UTC ---
Author: ebotcazou
Date: Sat Oct 20 21:00:23 2012
New Revision: 192641
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192641
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54315
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224
--- Comment #15 from janus at gcc dot gnu.org 2012-10-20 21:17:54 UTC ---
(In reply to comment #14)
(In reply to comment #12)
* unused-warnings for module variables
Here is a draft patch which fixes the test case in comment 14:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54997
--- Comment #4 from janus at gcc dot gnu.org 2012-10-20 21:46:12 UTC ---
The following removes the warning for s3:
Index: gcc/fortran/trans-decl.c
===
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55003
Bug #: 55003
Summary: [C++11] Member function pointer not working as
constexpr initializer
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55002
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug #: 55004
Summary: [meta-bug] constexpr issues
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54998
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Severity|major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-20
23:21:42 UTC ---
Related to PR54768.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-20
23:31:41 UTC ---
Related to PR51675.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54991
--- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-10-21
02:47:32 UTC ---
Author: vmakarov
Date: Sun Oct 21 02:47:28 2012
New Revision: 192645
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192645
Log:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55005
Bug #: 55005
Summary: [4.8 Regression] gcc.c-torture/execute/loop-3.c FAILs
with -fPIC
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
On Tue, Oct 16, 2012 at 10:25 AM, Chung-Lin Tang
clt...@codesourcery.com wrote:
On 12/9/27 6:25 AM, Janis Johnson wrote:
On 09/26/2012 01:58 AM, Chung-Lin Tang wrote:
+/* { dg-do compile } */
+/* { dg-options -mthumb -O1 -march=armv5te -fno-omit-frame-pointer
-fno-forward-propagate } */
Joern Rennecke joern.renne...@embecosm.com writes:
Quoting Richard Sandiford rdsandif...@googlemail.com:
Joern Rennecke joern.renne...@embecosm.com writes:
Quoting Richard Sandiford rdsandif...@googlemail.com:
The fact that we even have shared unique ids is pretty bad -- and surely
a
Joern Rennecke joern.renne...@embecosm.com writes:
@@ -1165,6 +1175,7 @@ shorten_branches (rtx first ATTRIBUTE_UN
get the current insn length. If it has changed, reflect the change.
When nothing changes for a full pass, we are done. */
+ bool first_pass ATTRIBUTE_UNUSED =
Hi,
this patch fixes BUILT_IN_UNREACHABLE declaration of C frontned. The function
is also pure (so DSE can do its job). As a special case ECF flags for
CONST NORETURN also add looping, so this declaration is correct.
The implicit declaration of the builtin is already set this way.
Quoting Richard Sandiford rdsandif...@googlemail.com:
I think instead the set-up loop should have:
if (GET_CODE (body) == ADDR_VEC || GET_CODE (body) == ADDR_DIFF_VEC)
{
#ifdef CASE_VECTOR_SHORTEN_MODE
if (increasing GET_CODE (body) == ADDR_DIFF_VEC)
Hi,
Quite a few tests fail for big-endian multilibs which use VFP
instructions at present. One reason for many of these is glaringly
obvious once you notice it: for D registers interpreted as two S
registers, the lower-numbered register is always the less-significant
part of the value, and the
Joern Rennecke joern.renne...@embecosm.com writes:
Quoting Richard Sandiford rdsandif...@googlemail.com:
I think instead the set-up loop should have:
if (GET_CODE (body) == ADDR_VEC || GET_CODE (body) == ADDR_DIFF_VEC)
{
#ifdef CASE_VECTOR_SHORTEN_MODE
if (increasing
* expmed.c (lowpart_bit_field_p): New function.
(store_bit_field_1): Remove unit, offset, bitpos and byte_offset
from the outermost scope. Express conditions in terms of bitnum
rather than offset, bitpos and byte_offset. Split the plain move
cases into two, one
Hi,
the TLC path I sent last week became outdated for few reaons. I decided to
split it up for easier reviewing.
This is simple correcntess issue I am comitting as obvoius - my last update to
loop-iv missed the fact
that loop-iv bounds may depend on further conditions. In that case we can not
What about the conservative variant of simply
else
delta = double_int_one;
I think it would be bad idea: it makes us to completely unroll one
interation
too many that bloats code for no benefit. No optimization cancels the
path in
CFG because of
After recent patches there were too many regressions of LRA on GCC
testsuite on x86 and x86-64.
The following patch fixes all of them.
It was successfully bootstrapped on x86/x86-64.
Committed as rev. 192637.
2012-10-20 Vladimir Makarov vmaka...@redhat.com
* lra.c (check_rtx):
Hi,
this patch fixes heuristic on decide_unroll_constant_iterations to take into
account the profile: even when the loop is known to have constant loop
iteration bound, it doesn't need to really iterate many times. So use profile
and loop_max to double check that this is the case.
On 10/19/2012 11:41 PM, Ramana Radhakrishnan wrote:
On Tue, Oct 16, 2012 at 10:25 AM, Chung-Lin Tang
clt...@codesourcery.com wrote:
On 12/9/27 6:25 AM, Janis Johnson wrote:
On 09/26/2012 01:58 AM, Chung-Lin Tang wrote:
+/* { dg-do compile } */
+/* { dg-options -mthumb -O1 -march=armv5te
The patch was fully tested on x86_64-suse-linux, where it removes half of
the useless stores in the original testcase for PR rtl-optimization/54315,
and manually tested for arm-linux-gnueabi (for now), where it also removes
stores for small structures. Comments?
2012-10-08 Eric Botcazou
On Wed, 10 Oct 2012, Andreas Krebbel wrote:
the attached patch adds initial support for the latest release of
the IBM mainframe series - the IBM zEnterprise EC12 (zEC12).
Nice. Can you please also add a note to the release notes at
gcc-4.8/changes.html ?
In principle, I'm also in favor of
On Sat, Oct 20, 2012 at 4:38 AM, Julian Brown jul...@codesourcery.com wrote:
Hi,
Quite a few tests fail for big-endian multilibs which use VFP
instructions at present. One reason for many of these is glaringly
obvious once you notice it: for D registers interpreted as two S
registers, the
...and some other simplifications and improvements I noticed on
the way.
This was triggered by a note that the sources.redhat.com DNS entry
is going to go away at some point in the future that I got yesterday.
Applied.
Gerald
2012-10-21 Gerald Pfeifer ger...@pfeifer.com
*
The following patch fixes PR54991.
Committed as rev. 192645.
2012-10-20 Vladimir Makarov vmaka...@redhat.com
PR rtl-optimization/54991
* lra-constraints.c (lra_constraints): Change equiv memory check
on reverse equivalence check.
(inherit_in_ebb): Invalidate usage insns for
With a simulator that doesn't just allocate zeros on any access, it's
necessary to tell the simulator the bounds of defined memory, both for
static and dynamically allocated memory. This patch implements static
code and data allocatation; zero'd data and constants may not be
otherwise loaded. A
CC:ing middle-end maintainers this time. I was a bit surprised
when Eric Botcazou wrote in his review, quoted below, that he's
not one of you. Maybe approve that too?
On Mon, 15 Oct 2012, Hans-Peter Nilsson wrote:
On Fri, 12 Oct 2012, Eric Botcazou wrote:
(insn 168 49 51 3 (set (reg/f:DI
For mmix-knuth-mmixware, MAX_FIXED_MODE_SIZE is the default,
GET_MODE_BITSIZE (DImode), which of course isn't larger than the
size-type, the same size on this 64-bit target. I don't think making
it larger (i.e. TImode) would help: that seems instead likely to
introduce awkward spurious
87 matches
Mail list logo
