http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
CC||glisse at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
--- Comment #42 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2012-04-29 09:25:24 UTC ---
Author: paolo
Date: Sun Apr 29 09:25:17 2012
New Revision: 186944
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186944
Log:
2012-04-29 Marc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Gabriel Dos Reis gdr at gcc dot gnu.org changed:
What|Removed |Added
CC||gdr at gcc dot
--- Comment #31 from paolo dot carlini at oracle dot com 2010-02-21 09:51
---
(In reply to comment #30)
Wouldn't it be a violation of the one definition rule (ODR),
when one translation unit is compiled with -fwrapv and another without?
In that case this would be a regression.
I
--- Comment #32 from veksler at il dot ibm dot com 2010-02-21 12:44 ---
(In reply to comment #31)
(In reply to comment #30)
Wouldn't it be a violation of the one definition rule (ODR),
when one translation unit is compiled with -fwrapv and another without?
In that case this
--- Comment #33 from paolo dot carlini at oracle dot com 2010-02-21 12:53
---
(In reply to comment #32)
If this hazard is so prevalent shouldn't it deserve a separate PR?
If a method or function depend on a flag or macro then it can be handled
by overloading and specialization
--- Comment #34 from rguenth at gcc dot gnu dot org 2010-02-21 13:04
---
(In reply to comment #33)
(In reply to comment #32)
If this hazard is so prevalent shouldn't it deserve a separate PR?
If a method or function depend on a flag or macro then it can be handled
by overloading
--- Comment #35 from veksler at il dot ibm dot com 2010-02-21 13:33 ---
(In reply to comment #34)
(In reply to comment #33)
(In reply to comment #32)
If this hazard is so prevalent shouldn't it deserve a separate PR?
If a method or function depend on a flag or macro then it can
--- Comment #36 from rguenther at suse dot de 2010-02-21 13:37 ---
Subject: Re: numeric_limitssigned::is_modulo is
inconsistent with gcc
On Sun, 21 Feb 2010, veksler at il dot ibm dot com wrote:
Or suspend it. I think this warrants a defect report anyway since I think
is_modulo
--- Comment #37 from gdr at integrable-solutions dot net 2010-02-21 18:04
---
Subject: Re: numeric_limitssigned::is_modulo is
inconsistent with gcc
On Sun, Feb 21, 2010 at 7:04 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
Or suspend it. I think this
--- Comment #38 from veksler at il dot ibm dot com 2010-02-21 18:20 ---
(In reply to comment #37)
is_modulo is intended to describe the implementation's choice, not necessarily
the CPU behaviour (which the implementation may choose to mask or not.)
The issue here is that GCC does
--- Comment #39 from gdr at integrable-solutions dot net 2010-02-21 18:50
---
Subject: Re: numeric_limitssigned::is_modulo is
inconsistent with gcc
On Sun, Feb 21, 2010 at 12:20 PM, veksler at il dot ibm dot com
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #38 from
--- Comment #30 from veksler at il dot ibm dot com 2010-02-21 07:52 ---
(In reply to comment #25)
It would probably be useful to add a preprocessor macro when -fwrapv is
in effect.
Wouldn't it be a violation of the one definition rule (ODR),
when one translation unit is compiled
--- Comment #25 from rguenth at gcc dot gnu dot org 2010-02-19 10:22
---
(In reply to comment #24)
Richard, can you comment on this issue? Do you think it's currently correct to
have numeric_limits:is_modulo == true for all our signed integral types? We
are not making any progress
--- Comment #26 from paolo dot carlini at oracle dot com 2010-02-19 10:30
---
Ah, thanks, that pre-processor macro idea looks very nice to me. Let's see what
people think, and in case, I'll take care of that as soon as 4.5 branches.
--
paolo dot carlini at oracle dot com changed:
--- Comment #27 from joseph at codesourcery dot com 2010-02-19 11:13
---
Subject: Re: numeric_limitssigned::is_modulo is
inconsistent with gcc
The issue with -fwrapv not making INT_MIN / -1 and INT_MIN % -1 have
modulo semantics is discussed in bug 30484.
--
--- Comment #28 from paolo dot carlini at oracle dot com 2010-02-19 11:18
---
Thanks Joseph. Indeed, I remember well when my friend Roberto opened that
issue, but didn't expect it was still open ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
--- Comment #29 from paolo dot carlini at oracle dot com 2010-02-19 11:26
---
So, if I understand correctly the dependencies, I think we should mark this as
blocked by 30484: when -fwrapv makes INT_MIN / -1 and INT_MIN % -1 have modulo
semantics we can conditionalize
--- Comment #24 from paolo dot carlini at oracle dot com 2010-02-18 22:03
---
Richard, can you comment on this issue? Do you think it's currently correct to
have numeric_limits:is_modulo == true for all our signed integral types? We
are not making any progress on this issue :(
--
20 matches
Mail list logo
