http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46394
--- Comment #2 from Marc Glisse 2010-12-17
20:04:18 UTC ---
Note that if I change the function to:
template,
void
>::value
>::type
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47172
Summary: [C++0x] cannot call member function without object
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823
--- Comment #12 from Marc Glisse 2011-01-07
23:47:35 UTC ---
(In reply to comment #11)
> It does not reproduce for me, perhaps it was fixed by the recursive inliner
> fix?
Did you try with a.cc? ouin.cc hasn't reproduced for a while. I just chec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47313
Summary: ICE: PHI argument is not a GIMPLE value
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47313
--- Comment #1 from Marc Glisse 2011-01-16
09:35:27 UTC ---
Created attachment 22981
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22981
testcase
Try again to attach it, bugzilla apparently failed to upload it in the initial
bug report.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47380
Summary: concept checking and incomplete types
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47380
--- Comment #4 from Marc Glisse 2011-01-20
19:40:29 UTC ---
(In reply to comment #1)
> Yes it is, and no, we are not going to "fix" the legacy simulated concepts, we
> are barely keeping the code, for now.
Ok. If it is a "legacy", would you mind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47380
--- Comment #8 from Marc Glisse 2011-01-20
20:29:22 UTC ---
Thank you, the new paragraph is great :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47511
Summary: [C++0x] ICE: unexpected ast of kind template_decl in
potential_constant_expression_1, at
cp/semantics.c:7711
Product: gcc
Version: 4.6.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46341
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518
--- Comment #9 from Marc Glisse 2011-02-25
11:05:58 UTC ---
(In reply to comment #8)
> Ideally, we should figure in which release has been fixed. Do you think the
> small testcase in Comment #3 summarizes well the issue? Apparently works with
> 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46466
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
Summary: [C++0x] improve ratio_add to overflow less often
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
--- Comment #2 from Marc Glisse 2011-02-27
19:12:07 UTC ---
(In reply to comment #1)
> Looks like there is a pretty simple (eg, no continued fractions & co) way to
> do
> this:
The continued fraction thing for ratio_less may actually be easier:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42622
--- Comment #1 from Marc Glisse 2011-02-28
07:49:42 UTC ---
Created attachment 23487
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23487
proposed fix
Not thoroughly tested, but it seems to pass comp1.cc and comp2.cc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42622
--- Comment #4 from Marc Glisse 2011-02-28
14:45:42 UTC ---
(In reply to comment #3)
> I think the patch is small enough
> to go in at your name without Copyright Assignment.
I believe I am supposed to have the paperwork in order now. Would you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
--- Comment #5 from Marc Glisse 2011-03-01
22:15:48 UTC ---
Created attachment 23509
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23509
Overkill
I was having a hard time making it nice and clean, so I went for totally
overkill. It might b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
--- Comment #7 from Marc Glisse 2011-03-02
09:59:52 UTC ---
(In reply to comment #6)
> 1- Please make sure the code is minimally documented (are the comments in
> longlong.h enough?)
Ok, I wasn't sure it was worth it if the code was unlikely to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
--- Comment #9 from Marc Glisse 2011-03-02
11:50:41 UTC ---
(In reply to comment #8)
> Right. Mine was sort of a general comment: the comments in ratio_less are also
> rather terse ;)
I'll try to expand a bit on them.
> I don't think you should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
--- Comment #10 from Marc Glisse 2011-03-02
11:53:58 UTC ---
Created attachment 23512
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23512
avoid denominator overflows (untested)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
--- Comment #13 from Marc Glisse 2011-03-02
14:05:23 UTC ---
(In reply to comment #11)
> Thanks for the attachment. Do you have a small testcase for it? I would test
> here, commit, and then we can proceed with more serious changes for post
> 4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42622
--- Comment #8 from Marc Glisse 2011-03-02
14:58:06 UTC ---
Created attachment 23514
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23514
4 lines of comments...
It might be better to write a single paragraph explaining the algo instead of a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
--- Comment #17 from Marc Glisse 2011-03-02
20:50:42 UTC ---
Some more examples. Using the constants:
m=INTMAX_MAX;
n=INTMAX_MAX/2;
p=((intmax_t)1<<(4*sizeof(intmax_t)-1))-3
(m,2)-(m,3)==(m,6) boost should manage this one
(m/7*5-1,5)-(m-2,7)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
--- Comment #19 from Marc Glisse 2011-03-03
06:41:45 UTC ---
(In reply to comment #18)
> I'm not sure to understand, I was under the impression that right now GCC is
> essentially equal to boost::rational?!?
That's the heuristic I was mentioning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47380
--- Comment #11 from Marc Glisse 2011-08-23
15:27:35 UTC ---
In case someone else has issues with _GLIBCXX_CONCEPT_CHECKS, all the bad cases
I have hit came from _SGIAssignableConcept, so I simply removed the content of
that concept (not very sub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50167
Bug #: 50167
Summary: gmp memory functions are extern "C" (graphite)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50153
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #7 from Marc Glisse 2011-08-23
18:35:57 UTC ---
If I understand correctly, operator< is supposed to give a lexicographic order,
and vector stores {true,false,false} as 1 and {false,false,true} as 4, so
we can't just make operator< com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #11 from Marc Glisse 2011-08-23
19:16:40 UTC ---
(In reply to comment #8)
> For my application I should simply use an unordered_map and all the overhead
> has gone. :D
Great.
> “I haven't thought about the potential drawbacks of imp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50177
Bug #: 50177
Summary: libcpp reallocator a C or C++ function?
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #20 from Marc Glisse 2011-08-30
00:20:07 UTC ---
Created attachment 25134
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25134
remember linkage of a function type
This is an extremely basic patch, that probably misses many things
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #22 from Marc Glisse 2011-08-30
09:32:24 UTC ---
(In reply to comment #21)
> I'll try your patch and see what, if anything, can be changed safely in
> libstdc++ right away.
Thanks :-)
Note that some things are painful to do right wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #25 from Marc Glisse 2011-08-30
11:28:48 UTC ---
(In reply to comment #23)
> I think you can do it with a alias-declaration in an extern "C" block:
>
> extern "C" {
> template
> using func_type = T (*)();
> }
>
> extern "C" voi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #28 from Marc Glisse 2011-08-30
12:34:20 UTC ---
(In reply to comment #27)
> this is DR13 btw
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#13
> I don't know if that's been reconsidered now we have attributes
Gah, I lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Marc Glisse changed:
What|Removed |Added
Attachment #25134|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #30 from Marc Glisse 2011-08-30
20:32:57 UTC ---
(In reply to comment #29)
> New version that works with typedefs (I was forgetting extern "C" in the
> canonical type...). The patch also includes a workaround for __stoa. There
> seems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #31 from Marc Glisse 2011-08-31
13:40:28 UTC ---
(In reply to comment #25)
> (In reply to comment #23)
> > I think you can do it with a alias-declaration in an extern "C" block:
> >
> > extern "C" {
> > template
> > using func_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
Bug #: 50268
Summary: [C++0x] bitset doesn't sanitize input
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #6 from Marc Glisse 2011-09-02
08:03:22 UTC ---
(In reply to comment #5)
> This one is much better, and actually should lead to slightly better code than
> C++98, because we don't do anything if _Nw > 1 (the 32-bit case is also better
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #11 from Marc Glisse 2011-09-02
10:59:46 UTC ---
(In reply to comment #10)
> (by the way, if you can see a neat enough way to improve _M_are_all_aux, you
> are welcome to propose it! I'm definitely not an expert in this area, and when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #13 from Marc Glisse 2011-09-02
12:23:33 UTC ---
(In reply to comment #12)
> Created attachment 25178 [details]
> Work in progress patch for the _M_are_all_aux issue
>
> I'm considering doing something like this: what do you think? C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #16 from Marc Glisse 2011-09-02
13:26:14 UTC ---
(In reply to comment #15)
> I'm finishing testing this.
Looks good, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Marc Glisse changed:
What|Removed |Added
Attachment #25140|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #33 from Marc Glisse 2011-09-04
11:03:41 UTC ---
And if you don't like errors saying that X can't be converted to X, you'll need
something like the below. I don't think I'll go much further anytime soon (if
someone else wants a go, tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906
--- Comment #5 from Marc Glisse 2011-09-05
09:58:19 UTC ---
(In reply to comment #4)
> IMO the example program is broken and cannot be used to proof violation of
> contract of the library. This is so, because istreambuf_iterator is an input
> ite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906
--- Comment #7 from Marc Glisse 2011-09-05
12:38:13 UTC ---
(In reply to comment #6)
> 1) The fact that repeated calls of operator* without intervening operator++
> calls produce the same result for a given iterator object is required by
> expres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906
--- Comment #9 from Marc Glisse 2011-09-05
14:01:08 UTC ---
(In reply to comment #8)
> Why do you think that either implementation form could be
> considered as non-conforming?
When I read that operator* returns sgetc(), I understand that as
as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906
--- Comment #11 from Marc Glisse 2011-09-05
15:05:56 UTC ---
(In reply to comment #10)
> > When I read that operator* returns sgetc(), I understand that as
> > assert(*i==buf.sgetc()).
> But as explained below this requires that no further exter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665
--- Comment #1 from Marc Glisse 2011-09-06
21:11:40 UTC ---
Created attachment 25210
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25210
Fix libiberty demangler
This patch seems to fix c++filt. It doesn't change anything to the g++ issues.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50336
Bug #: 50336
Summary: LWG issue 445
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19805
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50384
Bug #: 50384
Summary: Copying a char array
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50384
--- Comment #1 from Marc Glisse 2011-09-14
08:23:15 UTC ---
Don't know if it is the same problem, but gcc seems to have trouble optimizing
with structs:
//typedef struct A { unsigned char t; } A;
typedef unsigned char A;
extern A f(A,A);
A g(A x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #34 from Marc Glisse 2011-09-15
16:53:33 UTC ---
I posted a related demangler patch on gcc-patches a couple weeks ago, let me
just link it from here so it doesn't get lost:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00231.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441
--- Comment #2 from Marc Glisse 2011-09-17
09:30:25 UTC ---
Actually, gcc documents that __int128 is *not* an extended integer type:
http://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html
(the comment in the source file specifically menti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441
--- Comment #14 from Marc Glisse 2011-09-18
06:28:32 UTC ---
(In reply to comment #10)
> I'd like to have some help about the best way to figure out whether the target
> supports __int128_t and __uint128_t: is __CHAR_BIT__ * __SIZEOF_LONG__ >= 64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #27 from Marc Glisse 2011-09-22
09:25:44 UTC ---
(In reply to comment #25)
[builtins to reverse the bit order]
> I think a separate Bugzilla requesting as an enhancement such intrinsics would
> be certainly appropriate.
Has this RFE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481
Bug #: 50481
Summary: builtin to reverse the bit order
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #29 from Marc Glisse 2011-09-22
10:29:07 UTC ---
See Bug 50481 about bit-reversal builtins (and feel free to add details there).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #121 from Marc Glisse
2011-09-28 14:20:09 UTC ---
(In reply to comment #120)
> Last plea for Standards conformance: What about only setting the correct
> define
> if -std=c++89/03/0x/11 is passed and keeping the old behavior for -std=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #6 from Marc Glisse 2011-10-08
10:59:31 UTC ---
(In reply to comment #5)
> The analogy with copying and traits is enticing, but before reading Marc's
> message, I wondered: for pointers, which kind of improvement are we talking
> abou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50677
Bug #: 50677
Summary: volatile forces load into register
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665
--- Comment #5 from Marc Glisse 2011-10-10
05:55:10 UTC ---
(In reply to comment #4)
> It's mainly a matter of style, but this is the approach I prefer.
Thanks, it looks nicer indeed :-)
Would you care to commit (or submit) your patch? Or can I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665
Marc Glisse changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
--- Comment #4 from Marc Glisse 2011-10-11
12:24:18 UTC ---
And anyway 10^-6 is not representable exactly as a double.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
--- Comment #10 from Marc Glisse 2011-10-14
21:12:40 UTC ---
As a library writer, having isnan return false is precisely what I am expecting
from -ffinite-math-only. In my code, I implement regular computations for
finite numbers, and I need some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
--- Comment #13 from Marc Glisse 2011-10-15
09:05:57 UTC ---
(In reply to comment #11)
> I'm guessing (and apologies if this is inaccurate) that this might boil down
> to
> saying that you want to interpret an end user setting -ff-m-o as an
> o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829
Bug #: 50829
Summary: avx extra copy for _mm256_insertf128_pd
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829
--- Comment #2 from Marc Glisse 2011-10-22
17:01:51 UTC ---
(In reply to comment #1)
> This looks similar to PR 34283, a RA problem.
Ah, indeed. I also had a function that ended with:
vmovapd%xmm1, %xmm0
vmaxpd%xmm2, %xmm0, %xmm0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829
--- Comment #3 from Marc Glisse 2011-10-23
08:20:50 UTC ---
(In reply to comment #1)
> This looks similar to PR 34283, a RA problem.
PR 48037 too. I didn't find all of those before reporting because I was looking
for something AVX-specific, sorr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
--- Comment #13 from Marc Glisse 2011-10-28
10:18:43 UTC ---
(In reply to comment #12)
> (In reply to comment #10)
> > An iterator is either a pointer or a class with the
> > typedefs.
>
> Or a type for which iterator_traits has been specialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51013
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51013
--- Comment #6 from Marc Glisse 2011-11-08
07:44:27 UTC ---
(In reply to comment #4)
> I'm sorry, I misunderstood you, you meant C++11 does not mandate the constexpr
> in the primary. Actually, I guess it doesn't hurt,
I agree, it was your expre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51013
--- Comment #9 from Marc Glisse 2011-11-08
15:51:52 UTC ---
(In reply to comment #8)
> I meant that with the current libstdc++ complex, this is valid:
>
> constexpr float f = complex(2.4).real();
>
> but adding a non-constexpr overload would ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
Bug #: 51033
Summary: Partial vector extension support
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #2 from Marc Glisse 2011-11-08
17:13:39 UTC ---
It's probably doable, but it sounds like you have to duplicate all the logic
that is currently in the various backends (and some in the C front-end and the
middle-end I guess). The shuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51013
--- Comment #11 from Marc Glisse 2011-11-08
18:40:13 UTC ---
(In reply to comment #10)
> (In reply to comment #8)
> > Once we have ref-qualifiers, it should be OK to add the non-const overload
> > with
> > an lvalue ref-qualifier, though.
>
> I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #4 from Marc Glisse 2011-11-08
22:18:33 UTC ---
(In reply to comment #3)
> All vector support should also be in the C++ front-end. Can you give an
> example of something which does not work? Templates with vectors work already
> too
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #6 from Marc Glisse 2011-11-08
22:33:51 UTC ---
(In reply to comment #5)
> I am going to mark this as a regression because before both the C++ front-end
> and C front-ends were working with all vector extensions. This is really bad
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51078
--- Comment #8 from Marc Glisse 2011-11-10
17:28:46 UTC ---
Hello,
I can't seem to find a mention of the compiler flags you used for your
benchmarks, what are they? -Ofast -funroll-loops?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53153
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53131
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #11 from Marc Glisse 2012-04-28
12:33:26 UTC ---
(In reply to comment #9)
> It forgets to check first whether the first 2 ranges are trivial.
Or easier, instead of checking:
if (TREE_CODE (tem) != INTEGER_CST)
it could check in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #13 from Marc Glisse 2012-04-28
12:40:14 UTC ---
(In reply to comment #10)
> But there is something strange, because it is warning "it is always false",
> which is obviously not true. So I think at some moment it is doing some
> trans
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53131
--- Comment #6 from Marc Glisse 2012-04-28
12:45:19 UTC ---
(In reply to comment #5)
> It seems a pretty small warning, but I guess #1 and #2 could
> be split up, if that helps get #2 in.
I think it is the opposite actually, #2 is more controver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #15 from Marc Glisse 2012-04-28
12:55:28 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> >
> > Except that this version would warn for xINT_MAX, whereas this
> > belongs to other warnings. So testing the triviality of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #5 from Marc Glisse 2012-04-28
13:18:25 UTC ---
Created attachment 27260
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27260
Wrap using gmp
I find it easier to use bignum and wrap at the end, instead of checking for
each operat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #17 from Marc Glisse 2012-04-28
18:49:49 UTC ---
(In reply to comment #16)
> I understand now, and I think you are right. We don't have a warning for
> "((int)x) < INT_MIN" or ((int)x) > INT_MAX but I think it should go to
> Wtype-lim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
Bug #: 53155
Summary: Not parallel: test for -j fails
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
--- Comment #2 from Marc Glisse 2012-04-28
21:49:43 UTC ---
laptop-mg /tmp/m $ cat Makefile
all:
$(MAKE) plouf
plouf:
echo $(MFLAGS) "$(filter -j, $(MFLAGS))"
laptop-mg /tmp/m $ make -j
make plouf
make[1]: Entering directory `/tmp/m'
ec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #19 from Marc Glisse 2012-04-28
22:16:55 UTC ---
(In reply to comment #18)
> I'm afraid that false positives would still be likely.
> For example, suppose we're on a platform where
> INT_MAX = LONG_MAX < INTMAX_MAX. Then:
>
> intm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100
--- Comment #1 from Marc Glisse 2012-04-29
08:05:59 UTC ---
(In reply to comment #0)
> It would be convenient if I
> could just write the whole code with __int128 and let the compiler do the
> optimization by tracking the range of numbers.
The t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100
--- Comment #2 from Marc Glisse 2012-04-29
08:42:36 UTC ---
(In reply to comment #1)
> On the other hand, tree-vrp does have the information that the
> differences are in [-4294967295, 4294967295], which comfortably fits in a type
> half the size
1 - 100 of 308 matches
Mail list logo
