On July 3, 2014 1:06:30 AM CEST, Jason Merrill wrote:
>I think that makes sense; I'm not aware of anyone working on improving
>LTO debugging.
I've done that in the past. So it would be nice to verify we don't regress
existing tests.
Richard.
>Jason
Hi!
The following testcase is miscompiled on s390-linux (31-bit).
r202393 changed:
@@ -11946,11 +11949,11 @@
if (op1 == const0_rtx && (code == LT || code == GE)
On Wed, 2 Jul 2014, David Edelsohn wrote:
> * config/rs6000/rs6000.c (rs6000_adjust_atomic_subword): Use
> BYTES_BIG_ENDIAN rather than WORDS_BIG_ENDIAN to check for byte
> endianness.
>
> This patch is okay. Thanks for noticing it.
Committed, thanks.
Maciej
On Wed, Jul 02, 2014 at 04:06:30PM -0700, Jason Merrill wrote:
> I think that makes sense; I'm not aware of anyone working on improving LTO
> debugging.
I think at this point all we care about is that with -flto we don't ICE on
those, perhaps we should arrange to change all the tests into dg-do co
Cesar Philippidis wrote:
I couldn't find anything obvious in gcc/fortran/parse.c; is someone
able to have a more in-depth look than I have?
First, some minor point, I think one should crosswise reset the
{openmp,openacc}_flag, i.e.
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -735
On 2 July 2014 03:54, Jeff Law wrote:
> On 07/01/14 01:16, Zhenqiang Chen wrote:
>
>>
>> ChangeLog:
>> 2014-07-01 Zhenqiang Chen
>>
>> * loop-invariant.c (struct invariant): Add a new member: eqno;
>> (find_identical_invariants): Update eqno;
>> (create_new_invariant)
ok.
thanks,
David
On Wed, Jul 2, 2014 at 5:20 PM, Teresa Johnson wrote:
> New patch below. Retested. Ok for google branches?
>
> Thanks,
> Teresa
>
> 2014-07-02 Teresa Johnson
>
> Google ref b/15378201.
> * gcc/tree-profile.c (gcov_test_coverage_decl): Declare.
> (tre
On 06/26/2014 03:22 PM, Marek Polacek wrote:
The following is a revamped patch for -Wsizeof-array-argument.
Its purpose is to detect suspicious usage of the sizeof operator on an array
function parameter.
Then the name should be -Wsizeof-array-parm, not -argument.
@@ -9550,6 +9551,8 @@ grokde
On 07/02/2014 06:30 PM, Jan Hubicka wrote:
But this is one of things that was not quite clear to me. I know that
polymorphic type A
was created at a give memory location. THis means that accesses to that
location in one
alias class has been made.
Now I destroy A and turn it into B, construct
> > On 07/02/2014 01:18 PM, Jan Hubicka wrote:
> > >We propagate types from places we know instances are created across
> > >pointers
> > >passed to functions. Once non-POD type is created at a given memory
> > >location,
> > >one can not change its type by placement_new into something else.
> >
> On 07/02/2014 01:18 PM, Jan Hubicka wrote:
> >We propagate types from places we know instances are created across pointers
> >passed to functions. Once non-POD type is created at a given memory
> >location,
> >one can not change its type by placement_new into something else.
>
> Hmm. If the m
On 07/02/2014 12:02 PM, Tobias Burnus wrote:
> Thomas Schwinge wrote:
>> In -fopenmp mode as well as in combined -fopenacc -fopenmp mode as
>> well as in "regular" (no -fopen*) mode, it parses fine.
>
> [Note I am testing with an outdated branch (20140404), but it still
> might be representative.]
New patch below. Retested. Ok for google branches?
Thanks,
Teresa
2014-07-02 Teresa Johnson
Google ref b/15378201.
* gcc/tree-profile.c (gcov_test_coverage_decl): Declare.
(tree_init_instrumentation): Initialize gcov_test_coverage_decl.
* libgcc/libgcov-driver.
On 07/02/2014 01:18 PM, Jan Hubicka wrote:
We propagate types from places we know instances are created across pointers
passed to functions. Once non-POD type is created at a given memory location,
one can not change its type by placement_new into something else.
Hmm. If the memory location i
On 07/02/2014 03:34 PM, Trevor Saunders wrote:
On Wed, Jul 02, 2014 at 09:28:03PM +0200, Jan Hubicka wrote:
it seems to me this doesn't get at the real issue that the type names
are the same but the fields are different. maybe "a type of the same
name with different fields defined here"?
This
From: Trevor Saunders
Hi,
So apparently its not entirely obvious to everyone that removing the names of
unused arguments is the best way of dealing with warnings about unused
arguments in places like hooks where the argument is required for some reason.
Apparently this is somewhat less contraver
I think that makes sense; I'm not aware of anyone working on improving
LTO debugging.
Jason
On 06/30/14 15:37, Marc Glisse wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+ && !is_global_var (valbase))
+ || TREE_CODE
On 07/02/14 06:19, Alan Modra wrote:
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+
On 07/02/14 02:14, Jakub Jelinek wrote:
Hi!
Most of this probably doesn't need explanation, just the
expand_sdiv_pow2 change - shift_cost only tracks shift counts to
MAX_BITS_PER_WORD (but, for consistency between e.g. i?86 and x86_64 -m32
we'd better use BITS_PER_WORD instead as in most other e
On Wed, Jul 02, 2014 at 09:28:03PM +0200, Jan Hubicka wrote:
> >
> > I can't find the code for the SampleFormat thing, but the rest of them
> > look like ODR violations to me.
>
> I think it is some define renaming the field, I was also puzled by this one.
> >
> > > /aux/hubicka/firefox/netwerk/
Hi,
In parallel/unique_copy.h __counter is never deleted.
I'm also trying to follow from other posts how to submit a patch but
is well possible I missed some of the conventions. Many apologies if
that's the case.
libstdc++-v3/
* include/parallel/unique_copy.h: prevent memory leak of __counter
Firstly, it adds back the split conditions that I accidentally removed.
Without it the dot insns are never generated, or rather, always split
back to a separate compare instruction.
Secondly, the shift amount should be SI always, not GPR, or GCC will
insert a zero-extend at expand time that it can
The reason is that test coverage is using the same underlying
profiling. Returning false when calling '__gcov_profiling_enabled())
in coverage mode is a little misleading.
David
On Wed, Jul 2, 2014 at 1:22 PM, Teresa Johnson wrote:
> On Wed, Jul 2, 2014 at 1:15 PM, Xinliang David Li wrote:
>> S
On Wed, Jul 2, 2014 at 1:15 PM, Xinliang David Li wrote:
> Should the interface be something like:
>
> int __gcov_profiling_for_test_coverage(void)?
I was equating the term "profiling" with -fprofile-generate, as
opposed to -ftest-coverage instrumentation. But I can change it to
this if you think
> OK.
Thanks, committed.
> It would be useful if you could add one or more tests to the
> testsuite to confirm proper behaviour when only one of ROTATE/ROTATERT
> is defined.
I'll send a patch in a minute that tests this (as well as some other
things) for rs6000.
Segher
Hi,
this patch strengthens detect_type_change and makes it cheaper based on the
following observation.
We propagate types from places we know instances are created across pointers
passed to functions. Once non-POD type is created at a given memory location,
one can not change its type by placeme
Should the interface be something like:
int __gcov_profiling_for_test_coverage(void)?
David
On Wed, Jul 2, 2014 at 12:55 PM, Teresa Johnson wrote:
> The following patch adds support for a new libgcov interface,
> __gcov_profiling_enabled, that can be used by applications to
> determine whether
The following patch adds support for a new libgcov interface,
__gcov_profiling_enabled, that can be used by applications to
determine whether a binary has been instrumented for test coverage or
profile optimization.
Passes regression tests and manual testing with different options. Ok
for google b
>
> I can't find the code for the SampleFormat thing, but the rest of them
> look like ODR violations to me.
I think it is some define renaming the field, I was also puzled by this one.
>
> > /aux/hubicka/firefox/netwerk/sctp/datachannel/DataChannel.h:64:0: warning:
> > field ‘mSpa’ (of type ‘s
On Wed, Jul 02, 2014 at 05:15:20PM +0200, Jan Hubicka wrote:
> Hi,
> this patch adds structural comparsion into ODR warnings, so we do not rely
> on types_compatible_p to checks if the individual variants of same
> name looks same. This allows us to give more precise reason for the
> mismatch and
Thomas Schwinge wrote:
Reopening this oldie:
index 5fa42f4..68440d18 100644
--- a/libgomp/testsuite/libgomp.fortran/fortran.exp
+++ b/libgomp/testsuite/libgomp.fortran/fortran.exp
@@ -14,6 +14,7 @@ set quadmath_library_path "../libquadmath/.libs"
dg-init
if { $blddir != "" } {
+lapp
gcc/
* config/rs6000/rs6000.c (rs6000_adjust_atomic_subword): Use
BYTES_BIG_ENDIAN rather than WORDS_BIG_ENDIAN to check for byte
endianness.
This patch is okay. Thanks for noticing it.
Thanks, David
2014-07-02 Gerald Pfeifer
* news.html: Make a number of links relative.
* status.html: Ditto.
* libgcj-classpath-compare.html: Remove redundant link to gcc.css.
* gui-compare/libgcj-classpath-compare.html: Ditto.
Committed.
Yes, again this takes care of a numb
Mike Stump writes:
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape bytes in opcode). This situation happens
when REX prefix is used in SSE4 instructions. This patch tries to
avoid such situation by preferring xmm0-xmm7 usage
> On Jul 2, 2014, at 10:52 AM, Nathan Froyd wrote:
> > - Original Message -
> >> /aux/hubicka/firefox/netwerk/sctp/datachannel/DataChannel.h:64:0: warning:
> >> field ‘mSpa’ (of type ‘struct BufferedMsg’) violates one definition rule
> >> [-Wodr]
> >
> > Can we reword this warning? The "
On Jul 2, 2014, at 10:52 AM, Nathan Froyd wrote:
> - Original Message -
>> /aux/hubicka/firefox/netwerk/sctp/datachannel/DataChannel.h:64:0: warning:
>> field ‘mSpa’ (of type ‘struct BufferedMsg’) violates one definition rule
>> [-Wodr]
>
> Can we reword this warning? The "of type 'struc
On Tue, Jul 1, 2014 at 6:34 PM, Daniel Gutson
wrote:
> On Tue, Jul 1, 2014 at 2:25 PM, Jeff Law wrote:
>> On 03/19/14 08:06, Marcos Díaz wrote:
>>>
>>> Well, finally I have the assignment, could you please review this patch?
>>
>> Thanks.
>>
>> My first thought was that if we've marked the functi
Hi!
Reopening this oldie:
On Wed, 19 Dec 2012 16:38:41 +0100, Tobias Burnus wrote:
> The attached patch adds
> -fintrinsic-modules-path ${blddir}
> otherwise, the compiler might have trouble finding the libraries using
> "use, INTRINSIC :: omp_lib". Without "intrinsic" it searches the "-I"
- Original Message -
> /aux/hubicka/firefox/netwerk/sctp/datachannel/DataChannel.h:64:0: warning:
> field ‘mSpa’ (of type ‘struct BufferedMsg’) violates one definition rule
> [-Wodr]
Can we reword this warning? The "of type 'struct BufferedMsg'" could be easily
taken to mean that the typ
On Jul 2, 2014, at 9:27 AM, Jakub Jelinek wrote:
> On Wed, Jul 02, 2014 at 09:21:25AM -0700, Andi Kleen wrote:
>> Ilya Enkovich writes:
>>
>>> Silvermont processors have penalty for instructions having 4+ bytes of
>>> prefixes (including escape bytes in opcode). This situation happens
>>> when
Hello!
> Silvermont processors have penalty for instructions having 4+ bytes of
> prefixes (including escape
> bytes in opcode). This situation happens when REX prefix is used in SSE4
> instructions. This
> patch tries to avoid such situation by preferring xmm0-xmm7 usage over
> xmm8-xmm15 in
On Jul 2, 2014, at 1:14 AM, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
wide-int part, Ok.
> * wide-int-print.cc (print_decs): Negate UHWI instead of HWI.
> --- gcc/wide-int-print.cc.jj 2014-05-11 22:21:04.0 +0200
> +++ gcc/wide-int
On Wed, Jul 02, 2014 at 09:21:25AM -0700, Andi Kleen wrote:
> Ilya Enkovich writes:
>
> > Silvermont processors have penalty for instructions having 4+ bytes of
> > prefixes (including escape bytes in opcode). This situation happens
> > when REX prefix is used in SSE4 instructions. This patch t
Ilya Enkovich writes:
> Silvermont processors have penalty for instructions having 4+ bytes of
> prefixes (including escape bytes in opcode). This situation happens
> when REX prefix is used in SSE4 instructions. This patch tries to
> avoid such situation by preferring xmm0-xmm7 usage over xmm8
On 07/02/14 02:32, Eric Botcazou wrote:
So in order to known whether it's safe and optimal to use regs_ever_live
instead, the question is whether the passes after pass_free_cfg (are allowed
to) add or remove sets or clobbers of call_really_used_regs. I don't know
the full answer there.
pass_mac
Hi again,
On 07/02/2014 05:06 PM, Paolo Carlini wrote:
.. consider this patch withdrawn. I believe that something is going
wrong indeed as part of most_specialized_instantiation but the details
need to be figured out. I'm now focusing on fn_type_unification via
get_bindings.
In fact my typo ab
Hi,
this patch adds structural comparsion into ODR warnings, so we do not rely
on types_compatible_p to checks if the individual variants of same
name looks same. This allows us to give more precise reason for the
mismatch and also be more strict than canonical type merging.
Function odr_types_eq
.. consider this patch withdrawn. I believe that something is going
wrong indeed as part of most_specialized_instantiation but the details
need to be figured out. I'm now focusing on fn_type_unification via
get_bindings.
Paolo.
> Do you have modes whose size is not multiple of the unit?
Yes. That's exactly the problem I'm trying to solve here. I'm making
partial int modes have real corresponding types, and they can be any
bit size, with target PS*modes to match. The MSP430, for example, has
20-bit modes, 20-bit opera
On Wed, Jul 02, 2014 at 09:48:18AM +0200, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, we ICE on old style initialization of derived type
> components. ifort also rejects these, I think it doesn't make sense to
> support such initializations of derived type components.
>
> Bootstrapped/
This patch fixes libgo to not explicitly free tiny blocks when deleting
an entry from a map. The memory allocator now has a special case for
tiny objects (less than 16 bytes), and they can not be explicitly freed,
only garbage collected. This is PR go/61620. Bootstrapped and ran Go
testsuite on
On 02/07/14 08:52, Tom de Vries wrote:
> On 01-07-14 21:47, Jeff Law wrote:
>> On 07/01/14 13:27, Tom de Vries wrote:
>>> So my question is: is the combination of '&' and '+' supported ? If so,
>>> what is the exact semantics ? If not, should we warn or give an error ?
> >
>> I don't think we can
On 02 Jul 15:06, Tobias Burnus wrote:
> Hmm, I had hoped that the work would include the forward porting of HJ's
> patches from
> https://software.intel.com/en-us/articles/intel-manycore-platform-software-stack-mpss
> to the current trunk. In my understanding, that's all what is needed, isn't
> i
Hello Kirill,
On Wed, Jul 02, 2014 at 04:35:01PM +0400, Kirill Yukhin wrote:
> However, GCC (main trunk and this branch) does not support code generation
> for KNC
> and we don't plan to do that.
Hmm, I had hoped that the work would include the forward porting of HJ's
patches from
https://softw
On Wed, Jul 2, 2014 at 7:48 AM, Ramana Radhakrishnan
wrote:
> On Mon, May 5, 2014 at 8:21 AM, bin.cheng wrote:
>>
>>
>>> -Original Message-
>>> From: Richard Earnshaw
>>> Sent: Thursday, May 01, 2014 10:03 PM
>>> To: Bin Cheng
>>> Cc: gcc-patches@gcc.gnu.org
>>> Subject: Re: [PATCH ARM]Ha
On Wed, 2 Jul 2014, Alan Modra wrote:
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+
Hello Tobias
On 02 Jul 14:11, Tobias Burnus wrote:
> Kirill Yukhin wrote:
> > This branch should be capable to perform offload to Intel targets (Xeon PHI)
>
> Which Xeon PHI does it support? Knights Corner, Knights Landing, both?
Currently liboffloadmic supports KNC. Future update will add support
On Wed, Jul 02, 2014 at 11:05:23AM +0100, Maciej W. Rozycki wrote:
> As it
> happens both macros have the same value for the Power target
Thanks! Looks good to me. As you note above it is effectively a
documentation fix.
> --- gcc-fsf-trunk-quilt.orig/gcc/config/rs6000/rs6000.c 2014-06-1
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote:
> On Mon, 30 Jun 2014, Jeff Law wrote:
>
> >On 06/29/14 03:22, Marc Glisse wrote:
> >>
> >>After looking at PR 61597, I updated the 2 conditions to:
> >>
> >>+ if ((TREE_CODE (valbase) == VAR_DECL
> >>+ && !is_glob
Hello Kirill,
Kirill Yukhin wrote:
> This branch should be capable to perform offload to Intel targets (Xeon PHI)
Which Xeon PHI does it support? Knights Corner, Knights Landing, both?
Tobias
On 30 June 2014 14:26, Richard Earnshaw wrote:
> On 30/06/14 13:53, Charles Baylis wrote:
>> I see two options to fix it - one is to teach the back-end to
>> successfully generate code for this insn, and the other is to teach
>> the back-end that such an insn is not valid. My proposed patch does
>
> * Don't duplicate the logic for what's a hosted POSIX system; refactor it
> to a common fragment in config/ (I guess it needs to be a shell script
> fragment there rather than an actual autoconf macro, since you're using
> that logic in configure.tgt which is itself such a fragment).
I've attach
Hi,
Silvermont processors have penalty for instructions having 4+ bytes of prefixes
(including escape bytes in opcode). This situation happens when REX prefix is
used in SSE4 instructions. This patch tries to avoid such situation by
preferring xmm0-xmm7 usage over xmm8-xmm15 in those instruct
On Wed, Jul 2, 2014 at 11:16 AM, FX wrote:
> Thanks very much for the patch. I have a few questions:
>
>> the patch removes -O0 from dg-additiona-options in IEEE testsuite, as this
>> always override default optimization flag.
>
> That was my purpose: this test can fail with optimization (on x86
Hi,
While writing new guality.exp tests I noticed they often just fail
when ran with -flto, even though they PASS in all other cases. When
I asked on irc about this I was told that LTO was known to not play
well with DWARF debuginfo anyway. If that is the case, it seems better
to disable -flto for
Hi,
This change:
r199935 | amodra | 2013-06-11 07:17:50 +0100 (Tue, 11 Jun 2013) | 4 lines
* config/rs6000/rs6000.c (rs6000_adjust_atomic_subword): Calculate
correct shift value in little-endian mode.
Dear Uros,
Thanks very much for the patch. I have a few questions:
> the patch removes -O0 from dg-additiona-options in IEEE testsuite, as this
> always override default optimization flag.
That was my purpose: this test can fail with optimization (on x86_64, IIRC),
hence the -O0 should overrid
Hi all,
I've committed this patch as obvious with r212225. It fixes aarch64
bootstrap.
Cheers,
Kyrill
2014-07-02 Kyrylo Tkachov
* config/aarch64/aarch64.c (aarch64_expand_vec_perm): Delete unused
variable i.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
Hello!
Attached patch fixes some fallout from IEEE support and enables -mieee
for alpha. Also, the patch removes -O0 from dg-additiona-options in
IEEE testsuite, as this always override default optimization flag.
libgfortran/ChangeLog:
2014-07-02 Uros Bizjak
* configure.host (ieee_flags)
On 02 Jul 12:45, Kirill Yukhin wrote:
> Hello,
Pls disregard this mail and use previous one. Sorry.
--
Thanks, K
Jakub Jelinek wrote:
> As the testcase shows, we ICE on old style initialization of derived type
> components. ifort also rejects these, I think it doesn't make sense to
> support such initializations of derived type components.
Side remark: Cray ftn also rejects it, while PGI's compiler accepts
Hello,
I would like to announce creation of a dedicated branch gomp4-offload to speed
up review of FE-independent offload-related features.
This branch includes:
- set of necessary patches from gomp4 branch
- set of patches which we were developed internally and were unable to
share
Hello,
I would like to announce creation of a dedicated branch gomp4-offload to speed
up review of FE-independent offload-related features.
This branch includes:
- set of necessary patches from gomp4 branch
- set of patches which we were developed internally and were unable to
share
> So in order to known whether it's safe and optimal to use regs_ever_live
> instead, the question is whether the passes after pass_free_cfg (are allowed
> to) add or remove sets or clobbers of call_really_used_regs. I don't know
> the full answer there.
pass_machine_reorg is run after pass_free_c
> The whole point of using _PRECISION is to have the size be exactly the
> same as the mode (bitsize is bigger than the mode for partial-int
> modes). TYPE_SIZE_UNIT should be its storage size, right? If the
> type is not a multiple of BITS_PER_UNIT, the actual size and
> stored-in-memory size ar
This change is necessary to support Cortex-R based chips in RTEMS.
This patch should be applied to GCC 4.8, 4.9 and mainline. I do not
have write access, so in case this gets approved, please commit it for
me.
gcc/ChangeLog
2014-07-02 Sebastian Huber
* config/arm/t-rtems-eabi: Add
Hi!
Most of this probably doesn't need explanation, just the
expand_sdiv_pow2 change - shift_cost only tracks shift counts to
MAX_BITS_PER_WORD (but, for consistency between e.g. i?86 and x86_64 -m32
we'd better use BITS_PER_WORD instead as in most other expmed.c places),
when called with larger v
On 02-07-14 08:23, Marc Glisse wrote:
In the first example you gave, looking at the pattern (no match_dup, setting the
full register), it seems that it may have wanted "=&" instead of "+&".
[ move discussion from gcc ml to gcc-patches ml ]
Marcus,
The +& constraint on operand 0 of vec_unpack_
On 02/07/14 08:59, Christophe Lyon wrote:
Hi,
It seems some of the scan-assembler directives fail:
http://cbuild.validation.linaro.org/build/cross-validation/gcc/trunk/212196/aarch64-none-elf/diff-gcc-rh50-aarch64-none-elf-default-default-default.txt
Hi Christophe
Yes, turns out removing the
Hi,
It seems some of the scan-assembler directives fail:
http://cbuild.validation.linaro.org/build/cross-validation/gcc/trunk/212196/aarch64-none-elf/diff-gcc-rh50-aarch64-none-elf-default-default-default.txt
Christophe.
On 1 July 2014 14:13, Marcus Shawcroft wrote:
> On 23 June 2014 15:30, Ky
On 01-07-14 21:47, Jeff Law wrote:
On 07/01/14 13:27, Tom de Vries wrote:
So my question is: is the combination of '&' and '+' supported ? If so,
what is the exact semantics ? If not, should we warn or give an error ?
>
I don't think we can define any reasonable semantics for &+. My recommend
Hi!
As the testcase shows, we ICE on old style initialization of derived type
components. ifort also rejects these, I think it doesn't make sense to
support such initializations of derived type components.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.9?
2014-07-02 Jaku
Hi,
this patch adds predicate contains_polymorphic_type_p. This can be used
in the ICF pass - if one of the types is contains_polymorphic_type_p,
then TYPE_MAIN_VARIANTs of both types should be the same, at least for
now. Of course it would be possible to compare types for equality and then
also
84 matches
Mail list logo
