--- Comment #27 from jpr at csc dot fi 2008-02-14 08:12 ---
I think that the test program shown in comment #25 is invalid, as the main
program does not know about the call interface of the check_integer4_rank1()
function. If you add the module related lines in the comments, all is well
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-02-14
08:14 ---
And just think of the havoc that will be caused with old mingw32 and cygwin
libs that depend on the _chkstk meaning of __alloca if you change __alloca
semantics.
eg there are 69 undefined references to
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-14 08:15 ---
It would be helpful if you could post the actual errors that are reported for
the ICE, perhaps backtrace and other details. Guess most of the people don't
have access to this target and I doubt it can be reproduced us
--- Comment #6 from ktietz at gcc dot gnu dot org 2008-02-14 09:00 ---
I agree, that the havoc for 32-bit backward compatibility is to avoid.
But the havoc for windows sources using -fno-builtin and using _alloca () for
stack allocation produces in future even more troubles IMHO.
We all
--- Comment #6 from ktietz at gcc dot gnu dot org 2008-02-14 09:07 ---
Hello,
I tracked the problems down. Stack probing in builtin_alloca is the reason for
this. As I found, in some cases the input %rax argument isn't got set at all or
got clobbered before call to __chkstk.
The work-a-
--
george at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |george at gcc dot gnu dot
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-14 09:13 ---
It's probably still the same issue - in initializers we only fold builtin
functions, where the std:: variants are not recognized as such (they are
wrapper functions around the builtin). So this gets folded only afte
--- Comment #7 from ubizjak at gmail dot com 2008-02-14 09:19 ---
Just a shoot-in-the-dark question... does allocate_stack_worker_64 needs +a, as
is the case in allocate_stack_worker_32 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
--- Comment #8 from ktietz at gcc dot gnu dot org 2008-02-14 09:26 ---
I tested this already and it didn't solved the problem. But may +a is more
correct.
Cheers, Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-02-14 09:32 ---
x86_64-mingw is neither a primary nor a secondary target, also this PR is not
a regression as this target is new. So this clearly should not be P1 (though
technically it doesn't matter as this PR isn't a regression
--- Comment #10 from ubizjak at gmail dot com 2008-02-14 09:38 ---
(In reply to comment #8)
> I tested this already and it didn't solved the problem. But may +a is more
> correct.
Perhaps setting RTX_FRAME_RELATED_P is needed? Or gen_blockage() at some point?
--
http://gcc.gnu.org/
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-14 09:48 ---
Also please produce a complete compilable testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35188
--- Comment #29 from ubizjak at gmail dot com 2008-02-14 09:58 ---
(In reply to comment #28)
> With darwin bootstraps and regtest removal of the defines in
> cc/config/i386/darwin.h
Hm... I assume you did recompile libgfortran and libstdc++...
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #4 from tbptbp at gmail dot com 2008-02-14 10:02 ---
Hmm. If i correctly understand what you're saying, *cough*, ldexp should be
immune to this missed-folding-because-a-builtin-isn't-recognized-as-such; but
in the original code that lead to PR34774 there's nothing but ldexp,
--- Comment #11 from ktietz at gcc dot gnu dot org 2008-02-14 10:03 ---
May I find a point, where things aren't treated for 64-bit correctly for
Windows. In i386.c ix86_expand_prologue() there are stack pointer manipulation
operations using 4 byte offset for both targets (32 and 64). I a
--- Comment #30 from dominiq at lps dot ens dot fr 2008-02-14 10:09 ---
> Hm... I assume you did recompile libgfortran and libstdc++...
In comment #25 I have said:
> I bootstraped without the defines
Anyway, even if the change had solved the problem, I would not have considered
it as
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-14 09:41 ---
With 4.3 and checking enabled I get
/usr/include/c++/4.3/tr1_impl/boost_shared_ptr.h: In member function 'void
std::tr1::__shared_ptr<_Tp, _Lp>::reset(_Tp1*) [with _Tp1 = int, _Tp = int,
__gnu_cxx::_Lock_policy _Lp
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-14 09:44 ---
Alphabet/AlphIO.cpp:361: error: void value not ignored as it ought to be
so, this is not legal code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from steven at gcc dot gnu dot org 2008-02-14 10:10 ---
At least add a comment please why REG_CROSSING would need special treatment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35190
--- Comment #2 from steven at gcc dot gnu dot org 2008-02-14 10:12 ---
ICE on valid code should be P1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #28 from dominiq at lps dot ens dot fr 2008-02-14 09:46 ---
With darwin bootstraps and regtest removal of the defines in
cc/config/i386/darwin.h
I have the following for gfortran:
FAIL: gfortran.dg/c_f_pointer_tests.f90 -O0 execution test
FAIL: gfortran.dg/c_f_pointer_tes
--- Comment #5 from rguenther at suse dot de 2008-02-14 10:14 ---
Subject: Re: array constants after inlining
and "staticification"
On Thu, 14 Feb 2008, tbptbp at gmail dot com wrote:
> --- Comment #4 from tbptbp at gmail dot com 2008-02-14 10:02 ---
> Hmm. If i correctly un
--- Comment #3 from rguenther at suse dot de 2008-02-14 10:14 ---
Subject: Re: [4.2/4.3 Regression] ICE in coalesce_abnormal_edges
On Thu, 14 Feb 2008, steven at gcc dot gnu dot org wrote:
> --- Comment #2 from steven at gcc dot gnu dot org 2008-02-14 10:12
> ---
> ICE on va
--- Comment #6 from tbptbp at gmail dot com 2008-02-14 10:30 ---
Well, this was my best attempt so far at cornering that issue. I'm gonna wave a
dead chicken and try another attack vector. Sigh.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34864
--- Comment #12 from dominiq at lps dot ens dot fr 2008-02-14 10:36 ---
With the patch in comment #10, the ICE is fixed and I did not see any obvious
regression in 32 bit mode and gfortran 64 bit mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34930
--- Comment #3 from jakub at gcc dot gnu dot org 2008-02-14 10:48 ---
Subject: Bug 34962
Author: jason
Date: Wed Feb 13 21:27:16 2008
New Revision: 132297
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132297
Log:
PR c++/34962, c++/34937, c++/34939
* decl2.c (is_
--- Comment #2 from jakub at gcc dot gnu dot org 2008-02-14 10:49 ---
Subject: Bug 34962
Author: jason
Date: Wed Feb 13 21:27:16 2008
New Revision: 132297
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132297
Log:
PR c++/34962, c++/34937, c++/34939
* decl2.c (is_
--- Comment #2 from kkojima at gcc dot gnu dot org 2008-02-14 11:09 ---
Sure.
I'll add the following comment for that.
@@ -1105,9 +1105,14 @@ update_equiv_regs (void)
if (! INSN_P (insn))
continue;
- /* Don't substitute into a non-local goto, this confuse
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Keywords|wrong-code |
--- Comment #8 from paolo at gcc dot gnu dot org 2008-02-14 12:35 ---
Subject: Bug 28743
Author: paolo
Date: Thu Feb 14 12:34:42 2008
New Revision: 132316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132316
Log:
/cp
2008-02-14 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #9 from pcarlini at suse dot de 2008-02-14 12:37 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at s
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-02-14 12:42
---
I've posted a workaround patch at
http://gcc.gnu.org/ml/fortran/2008-02/msg00092.html. My analysis is currently
as follow: we currently have
static void * * C.906 = &argv;
glutinit_gl (&C.906);
which lea
--- Comment #31 from ubizjak at gmail dot com 2008-02-14 12:48 ---
(In reply to comment #30)
> participate to the discussion, but I think this PR only expose an underlying
> bug that should be analyzed.
>
> From what I understand, if *STACK_BOUNDARY is larger than the size of what is
>
--- Comment #13 from matz at gcc dot gnu dot org 2008-02-14 12:55 ---
Subject: Bug 34930
Author: matz
Date: Thu Feb 14 12:54:30 2008
New Revision: 132317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132317
Log:
PR target/34930
* function.c (instantiate_virtual_
--- Comment #14 from matz at gcc dot gnu dot org 2008-02-14 12:55 ---
Fixed in r132317.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
when I try to compile a current glibc for hppa, I get the following error:
gcc -O2 -c dcigettext.i
dcigettext.c: In function ‘_nl_find_msg’:
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:220: error: can't
find a register in class 'R1_REGS' while reloading 'asm'
dcigettext.c:1102: error:
--- Comment #1 from b dot gunreben at web dot de 2008-02-14 13:28 ---
Created an attachment (id=15148)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15148&action=view)
preprocessed dcigettext.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35193
In some situations (after a call to a C oracle function, or when running the
program on top of valgrind), floats behave strangely : a given, hard coded
float value displays erroneously.
For exemple, a float value of 1.2001 would print as "1.20831E+0".
Our analysis :
We reproduced the problem eithe
--- Comment #1 from jerome dot duquennoy at wanadoo dot fr 2008-02-14
13:38 ---
Created an attachment (id=15149)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15149&action=view)
Simple source code to reproduce the bug
Compile this code and run the resulting binary on top of valgr
--- Comment #34 from victork at gcc dot gnu dot org 2008-02-14 13:41
---
> How do I resolve those issues? which might prevent from the vectorized code to
> run and therefore I dont see a bigger performance improvement?
> I'd appriciate any assistance...
This note is just information an
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-14 13:43 ---
Reduced testcase, which shows this is inlining related and not related to
PR34989. Honza, can you have a look? After inlining we have:
:
# iter_6 = PHI
where clearly iter_6 should be marked abnormal? But I al
--- Comment #2 from jerome dot duquennoy at wanadoo dot fr 2008-02-14
13:44 ---
A precision on the appearance of the bug :
The bug first appears when using the Oracle 10 C library (libclntsh), and can
be reproduced using the Oracle 11 library.
The bug does not appear when using Oracle 9
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-14 13:46 ---
That is, somehow we split an edge:
+:
+ goto ;
+
:
- # iter_1(ab) = PHI
+ # iter_6 = PHI
+
+:
+ # iter_1(ab) = PHI
D.2093_4 = operator new (4);
:
but mess up somehow.
--
http://gcc.gnu.org/bugzill
--- Comment #12 from nightstrike at gmail dot com 2008-02-14 14:27 ---
Subject: Re: g++ inoperable with no error message
On 14 Feb 2008 08:15:35 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #5 from jakub at gcc dot gnu dot org 2008-02-14 08:15 -
--- Comment #13 from nightstrike at gmail dot com 2008-02-14 14:29 ---
Addendum - this applies to gfortran, as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
bash-3.2$ cat y.c
#include
int
main ()
{
#ifdef __MMX__
printf ("MMX\n");
#endif
#ifdef __3dNOW__
printf ("3dNOW\n");
#endif
#ifdef __3dNOW_A__
printf ("3dNOW_A\n");
#endif
}
bash-3.2$ /usr/gcc-4.3/bin/gcc -march=k8 -msse5 y.c && ./a.out
MMX
3dNOW
3dNOW_A
bash-3.2$ /usr/gcc-4.3/bin/gcc -ma
Szia!
Csak azert irok neked mert szeretnem felhivni a figyelemedet magyarorszag egyik
legnagyobb warez oldalara,ami nem reg keszult el es mar tobb 100 regisztralt
felhasznalonk van! a legujabb PREMIER filmek,mp3,games,sorozatok,stb Ha te is
csatlakozni szeretnel nezd meg az oldalunkat http://jo
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-14 14:48 ---
It used to compile with "4.3.0 20080128".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35183
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-02-14 14:55 ---
This is already fixed with "4.3.0 20080213".
*** This bug has been marked as a duplicate of 35116 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-02-14 14:55 ---
*** Bug 35183 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pcarlini at suse dot de 2008-02-14 15:40 ---
*** This bug has been marked as a duplicate of 34538 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #9 from pcarlini at suse dot de 2008-02-14 15:40 ---
*** Bug 33983 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-02-14 15:54 ---
I am going to take a look. Where we split the edge?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
--- Comment #5 from drow at gcc dot gnu dot org 2008-02-14 16:11 ---
Looks like it should be "do_it eq, t". Each additional "t" or "e" predicates
one more instruction. The mvfeqd has to be predicated and so does the
RETc(eq).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||openmp
Known to fail||4.3.0
Know
--- Comment #11 from drow at gcc dot gnu dot org 2008-02-14 16:31 ---
Might want to try at least one SPE target, for completeness. I think
powerpc-*-eabispe is sim testable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526
--- Comment #7 from rguenther at suse dot de 2008-02-14 16:16 ---
Subject: Re: [4.2/4.3 Regression] ICE in coalesce_abnormal_edges
On Thu, 14 Feb 2008, hubicka at gcc dot gnu dot org wrote:
> --- Comment #6 from hubicka at gcc dot gnu dot org 2008-02-14 15:54
> ---
> I am go
--- Comment #6 from joel at gcc dot gnu dot org 2008-02-14 16:30 ---
(In reply to comment #5)
> Looks like it should be "do_it eq, t". Each additional "t" or "e" predicates
> one more instruction. The mvfeqd has to be predicated and so does the
> RETc(eq).
>
Do you want to commit tha
extern void abort (void);
extern void omp_set_dynamic (int);
int
main (void)
{
int i, j;
omp_set_dynamic (0);
#pragma omp parallel for lastprivate (i, j) num_threads (8)
for (i = 0; i < 5; i++)
j = i;
if (i != 5 || j != 4)
abort ();
return 0;
}
fails with -fopenmp since
http://g
--- Comment #32 from ubizjak at gmail dot com 2008-02-14 17:08 ---
Dominique, could you regtest
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00507.html on darwin?
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from corsepiu at gcc dot gnu dot org 2008-02-14 17:26
---
Created an attachment (id=15150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15150&action=view)
patch implementing drow's proposal
I have no idea what this patch actually does, but it at least lets
arm-rte
--- Comment #2 from schwab at suse dot de 2008-02-14 17:35 ---
The problem is in the addsi_lshrsi_31 insn:
(define_insn "addsi_lshrsi_31"
[(set (match_operand:SI 0 "nonimmediate_operand" "=dm")
(plus:SI (lshiftrt:SI (match_operand:SI 1 "general_operand" "rm")
(const_in
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-02-14
17:46 ---
(In reply to comment #6)
> I agree, that the havoc for 32-bit backward compatibility is to avoid.
> But the havoc for windows sources using -fno-builtin and using _alloca () for
> stack allocation produ
I have a build of GCC 4.2.3 compiled with
--enable-version-specific-runtime-libs. It fails to link a trivial C++ program,
because the (non-GNU) linker does not know about libstdc++, and the GCC
frontend is not passing an appropriate -L... flag to the linker so that it can
find the library.
$ g++ -
I was recently bootstrapping GCC4 on Tru64. One thing that tripped me up a
couple times was an ICE resulting from an invalid version_string (""). I traced
this back to the following fragment in gcc/Makefile, where BASEVER_c is
assigned:
BASEVER := $(srcdir)/BASE-VER # 4.x.y
[...]
--- Comment #1 from skunk at iskunk dot org 2008-02-14 19:01 ---
Created an attachment (id=15151)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15151&action=view)
Patch against gcc/Makefile.in
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35199
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2008-02-14 19:10
---
Hopefully for real this time.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2008-02-14 19:08
---
Subject: Bug 35136
Author: ebotcazou
Date: Thu Feb 14 19:07:38 2008
New Revision: 132320
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132320
Log:
PR middle-end/35136
* gimplify.c (force
void* a(void* x) {return (int (*)[10][printf("hi\n")])x;}
int main() { int i; a(&i); }
should print hi. This was still broken in 4.3 in July, 2007.
--
Summary: missed evaluation of VM array type
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-14 19:33 ---
BASE-VER should always exist.
Also patches should be posted to [EMAIL PROTECTED]
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from hjl dot tools at gmail dot com 2008-02-14 19:52 ---
Created an attachment (id=15152)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15152&action=view)
A testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35200
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-14 19:57 ---
H, I think this might be a valid warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35200
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-14 20:00 ---
Oh there is an union here.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Gcc 4.3 revision 132310 gives bogus error when compiling binutils
on Linux/ia32:
[EMAIL PROTECTED] gas]$ /usr/gcc-4.3/bin/gcc -O2 x.i -S -Wall
x.c: In function operand_type_match:
x.c:1025: warning: likely type-punning may break strict-aliasing rules: object
*{unknown} of main type unsigned i
--- Comment #33 from dominiq at lps dot ens dot fr 2008-02-14 19:37 ---
> Dominique, could you regtest
I just finished a fresh build, I'll start to regtest as soon as the install is
finished, the full regtest takes approximately 5 hours, so the results will
only be available tomorrow mo
The C++ ABI at http://www.codesourcery.com/cxx-abi/abi.html defines:
::= C1 # complete object constructor
::= C2 # base object constructor
::= C3 # complete object allocating constructor
::= D0 # deleting destructor
::= D1 # complete object destructor
::= D2 # base objec
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-02-14 20:21 ---
Can you when you debug the function, please dump the VOPs also since then it
should become obvious the issue.
Anyways I don't think this an bogus warning and really I think this is a code
issue.
This is actually do
--- Comment #8 from dannysmith at users dot sourceforge dot net 2008-02-14
20:10 ---
(In reply to comment #7)
> If someone really wants an MSCV compatible (one underscore) _alloca they just
> add this to their srcs
> void *_alloca (size_t size) {return __builtin_alloca (size));
>
Ugh
--- Comment #4 from hjl dot tools at gmail dot com 2008-02-14 20:16 ---
The first time we saw it is last Nov. But it is very hard to reproduce.
Any changes in input will make the warning to disappear. Here is what
Xuepeng got
The warning are caused by SSA and type-punning:
[EMAIL PROTE
--- Comment #6 from hjl dot tools at gmail dot com 2008-02-14 20:54 ---
(In reply to comment #5)
> Can you when you debug the function, please dump the VOPs also since then it
> should become obvious the issue.
>
> Anyways I don't think this an bogus warning and really I think this is a
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-02-14 21:33 ---
Yes, so for packed structs (which are a GCCism), GCC sets the rule. Better
documentation is certainly appreciated, but - what is the bug here? Did
the behavior change (I think it did for some 3.x releases) recently
--- Comment #1 from dgregor at gcc dot gnu dot org 2008-02-14 21:38 ---
This code is actually ill-formed. The problem is here:
bind(h, forward(args...))
For N arguments, the second argument expands to:
bind(h, forward(args1, args2, ..., argsN))
However, that's ill-formed because
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-02-14 21:23 ---
See 6.5/6 and /7
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35200
--- Comment #4 from kengert at redhat dot com 2008-02-14 21:35 ---
Andrew, thanks a lot for your comments.
It turns out the bug was indeed caused by Mozilla code, see the Mozilla bug.
Closing as INVALID.
--
kengert at redhat dot com changed:
What|Removed
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-02-14 21:19 ---
ISO C even disallows type-punning with unions (which is in fact a GNU
extension):
union { int i; float f } u;
u.i = 1;
return u.f;
invokes undefined behavior in ISO C. You have to use memcpy and two different
memo
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
GCC converts calls such as (float)exp((double)f), where f is a float, into
calls to the corresponding mathematical functions for float, such as expf.
However, if the result overflows the range of float but not that of double, the
conversion is unsafe with -fmath-errno (on by default on most target
--- Comment #8 from alexandre dot nunes at gmail dot com 2008-02-14 22:06
---
(In reply to comment #7)
> Yes, so for packed structs (which are a GCCism), GCC sets the rule. Better
> documentation is certainly appreciated, but - what is the bug here? Did
> the behavior change (I think
On 14 Feb 2008 20:54:18 -, hjl dot tools at gmail dot com
<[EMAIL PROTECTED]> wrote:
> Where is this documented in ISO C?
There is a Defect Report explicitly about this:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_236.htm
-- Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #9 from pinskia at gmail dot com 2008-02-14 22:09 ---
Subject: Re: [4.3 Regression] bogus aliasing warning
On 14 Feb 2008 20:54:18 -, hjl dot tools at gmail dot com
<[EMAIL PROTECTED]> wrote:
> Where is this documented in ISO C?
There is a Defect Report explicitly abo
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-14 21:47 ---
Does the oracle library by any chance mess with the floating point precision
registers of the CPU?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35194
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-14 21:42 ---
Confirmed.
This used to work with gcc 2.95 at least.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-02-14
21:44 ---
Fixed
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #2 from dannysmith at gcc dot gnu dot org 2008-02-14 21:42
---
Subject: Bug 35061
Author: dannysmith
Date: Thu Feb 14 21:41:40 2008
New Revision: 132322
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132322
Log:
PR preprocessor/35061
gcc
* c-pragma.c
1 - 100 of 146 matches
Mail list logo
