--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-23 16:00 ---
Therefore the glibc fix is required to get the correct output.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-09-23 15:28 ---
>Side question: what could be the meaning of "sizeof (struct cl_decoded_option
*)"?
The size of the pointer (which can be useful sometimes but not in this case).
--
pinskia at gcc dot gnu do
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45728
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-22 17:42 ---
See the code in collect_execute:
if (HAVE_GNU_LD && at_file_supplied && argv[0] != NULL)
{
/* If using @file arguments, create a temporary file and put the
contents of argv into
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-22 16:42 ---
Can you provide the output of the -v command when you get that error? Also
what version of ld are you using?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-22 16:41 ---
I totally thought this was fixed in 4.5.0 when support was added because of
LTO.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2010-09-22 00:33
---
(In reply to comment #13)
> I seem to be getting this bug on arm thumb also
That is a different bug, see PR 38644. This bug records the PowerPC specific
bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
GCC target triplet||ia64-linux
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-20 04:52 ---
What binutils version are you using?
movteq is a valid ARM v7 instruction.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-20 04:27 ---
>-march=corei7 is successful.
Yes and that is kinda expected as --help does not process options at all
really.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-17 21:36 ---
manphiz: it's a bug
the build_debug and install_debug targets in libstdc++-v3/src/Makefile.am are
broken if you run configure using a relative path
the Makefile.am is broken
it does "cd debug &
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-17 20:35 ---
Not what is happening is an interaction between the inlining and the return
slot optimization and the named value optimization.
Before inlining we have:
# storage_1 = PHI <&.storage[0](2), &.s
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-17 20:25 ---
Reduced testcase:
struct Region {
int storage[4];
int count;
};
static inline Region subtract(int lhs)
{
Region reg;
int* storage = reg.storage;
if (lhs > 0)
storage++;
reg.count = stor
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-17 16:32 ---
This code depends on two undefined behavior. First it depends on an
uninitialized value of i. If i is greater than 0 to begin with it depends on
signed integer overflow which is undefined.
--
pinskia at gcc
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-17 15:19 ---
>ce1+combine removed it.
I think it still does on targets that don't have a direct to memory store of 0
like PPC.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-17 00:06 ---
(In reply to comment #2)
> I don't understand why the continuation character should be removed. For the C
> parser that character is not special (only for the C preprocessor it is), nor
> it confuses i
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-16 23:55 ---
C preprocessor is not a generic preprocessor. The continuation character is
removed so the correct line number is used.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-09-16 22:00 ---
GC issues normally don't show at different times depending on the layout of
memory and such. Sometimes it depends on env variables being slightly
different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build, GC, ice-on-valid-code
Summary|Dangling reference
--- Comment #138 from pinskia at gcc dot gnu dot org 2010-09-16 17:08
---
*** Bug 45691 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-16 17:08 ---
*** This bug has been marked as a duplicate of 323 ***
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #138 from pinskia at gcc dot gnu dot org 2010-09-16 17:08
---
*** Bug 45691 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-16 17:08 ---
*** This bug has been marked as a duplicate of 323 ***
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Keywords||wrong
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-15 21:00 ---
*** Bug 45684 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-15 21:00 ---
*** This bug has been marked as a duplicate of 43085 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-15 20:56 ---
D.1837_4 = () D.1836_3;
Looks like the support 128bit integer is not fully there for x86.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-14 22:35 ---
(In reply to comment #2)
> http://gcc.gnu.org/bugs/#need
Since this is a bug in the preprocessor it is hard to get a preprocessed source
that causes a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-14 22:34 ---
This is the same issue as PR 45362, PR 45362 has a description of what is
happening though it does show when it happened.
*** This bug has been marked as a duplicate of 45362 ***
--
pinskia at gcc dot gnu dot
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-14 22:34 ---
*** Bug 45666 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-13 17:58 ---
>void (*build_eri)();
In C means something different from:
void (*build_eri)(void);
Please try with the void.
--- CUT --
void (*build_eri)();
In C means that the build_eri takes a variable argume
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-12 14:11 ---
>This is caused by revision 160124:
Not really, it is a noreturn function so the behavior is correct for our policy
of allowing a more correct backtrace for noreturn functions. The testcase is a
incorrect
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-10 17:35 ---
This seems related to PR 45112.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-10 17:34 ---
I think you need __attribute((aligned(16))) on the original forward declared
class too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-10 17:20 ---
>libmpfr.so.1: undefined symbol: __gmp_get_memory_functions
That means libmpfr is finding the incorrect GMP. This is not a GCC bug but
rather a bug in your LD_LIBRARY_PATH or ld.so configuration.
--
pinskia
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-10 15:46 ---
>For volatile fields we should use accesses of the appropriate width.
The PowerPC ABI has specific rules for accessing volatile bitfields and IIRC it
says they should be doing the largest available (up to
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-10 15:30 ---
>1. index is constant or variable, and
Yes that is correct.
>2. the 'bar' field type.
The alignment of the access is different in those cases.
>In any case byte accesses should be used.
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-09-10 01:40 ---
(In reply to comment #3)
> Mozilla bugs say "Platform: x86 Linux". But gcc bug says
> "powerpc64-*-linux". What is going on?
I must have missed since I saw Linux64 I was thinking powerp
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-09 23:55 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-09 22:19 ---
PARAMETER are special as it is an exact replacement for those variables.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-09 22:17 ---
There have been no ABI changes in 4.5 that I know of for PowerPC64 or even
differences between the trunk and 4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-09 19:28 ---
>negative NAN.
Yes you can, the sign bit is set. But then again this is a glibc issue and not
a GCC issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-09 17:00 ---
>--with-cpu=arm926ej-s --with-tune=arm926ej-s --with-arch=armv5te
>--with-fpu=vfp --with-float=hard
Hmm, these default CPUs don't support vfp in thumb.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45616
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-09 07:27 ---
>I can use that as a quick workaround but I'll eventually need
__cxa_guard_acquire.
Then you should look into the ABI to see how it is defined. I think this ICE
only happens when it is declared inc
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-09 07:20 ---
>I first triggered this bug in a freestanding environment
You need to include -fno-threadsafe-statics to disable the use of
__cxa_guard_acquire. This functions is part of the normal C++ ABI we follow
(the IA6
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-09 01:17 ---
I think this is the same issue as PR 19816.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-09-08 19:01
---
vector types are naturally aligned just like integer types. That is they are
aligned on their size.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-09-08 19:01 ---
>If it's an illegal program, gcc should at least emit a warning, if not an
error.
It is not an invalid program, it is just undefined at runtime. There was a
defect report against the C standard ask
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-09-08 18:55 ---
The alignment of llvm_cbe__24__StackDv_P53 is only 64bits so you are casting to
a greater aligned type and then dereferencing it.
That being said, the LLVM C back-end produces crazy c code that is also
undefined
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-08 17:43 ---
Yes this is invalid with respect of alignment requirements.
It becomes obvious from the optimized at -O0 on the trunk.
v4df llvm_cbe_r5585;
v4df llvm_cbe_r5584;
struct l_DV1 llvm_cbe__24__StackDv_P53
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-08 17:39 ---
I think this code is undefined with respect of alignment requirements.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-08 15:04 ---
At one point we deprecated it and then undeprecated it. See PR 11569.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45599
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-08 14:46 ---
>#pragma once
Can you explain why you think it can be completely ignored? It can be used
without macro guards.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-07 23:19 ---
Just remove the -m32, people who care about -m32 will have use it while running
the testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45590
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-07 18:41 ---
ret_59 = (i_53 + 1) * 32 - (32 - ret_56)
So this looks like a re-association issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45256
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45559
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-09-06 06:48 ---
>I thought Stallman hated those things
The reason why Stallman hated them is that they did not work with macros and
that changed with C99 adding support of _Pragma which can be used in macros
now. So his argum
--- Comment #30 from pinskia at gcc dot gnu dot org 2010-09-06 05:39
---
*** Bug 45553 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-06 05:39 ---
It is still a dup of bug 11856. Note the use of bug here is really dealing
with how do you describe all issues (enhancements or otherwise). The use is
not saying it is a "software bug" in the no
--- Comment #29 from pinskia at gcc dot gnu dot org 2010-09-06 05:24
---
*** Bug 45553 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-06 05:24 ---
*** This bug has been marked as a duplicate of 11856 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-05 22:15 ---
Confirmed. zero_extendsidi2_32 and adddi3_doubleword are being split too late.
Which causes no optimizations to happen on those two things.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-05 06:41 ---
*** This bug has been marked as a duplicate of 41999 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-05 06:41 ---
*** Bug 45540 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41849
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-04 19:41 ---
std::make_pair< void*, int > takes rvalue references which cannot bind to
lvalues.
See the discussion in PR 43785.
*** This bug has been marked as a duplicate of 43785 ***
--
pinskia at gcc dot gnu d
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-09-04 19:41
---
*** Bug 45537 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-04 19:33 ---
(In reply to comment #1)
> Please provide a complete testcase, including Makefile.
The description has enough information to produce the issue. The driver is
producing a PCH and an executable with the same out
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-04 19:32 ---
This has enough information to reproduce the bug. Thanks again for the
testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-04 19:31 ---
The problem is the specs is producing the output file for the PCH.
[andrew-pinskis-computer:~] apinski% file t.out
t.out: GCC precompiled header (version 013) for C
Related to PR 33980.
--
pinskia at gcc
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-09-04 02:13
---
(In reply to comment #9)>
> --- gcc 2010-09-03 22:04:53.0 -0400
> +++ libgcc 2010-09-03 22:01:16.0 -0400
> @@ -11,34 +11,26 @@
>esac
> ],
> [
> - case $targ
--- Comment #27 from pinskia at gcc dot gnu dot org 2010-09-03 04:53
---
*** Bug 45497 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-03 04:53 ---
Not to mention t2.cpp is really a dup of bug 20681. And yes this is a dup of
that bug as this is a switch that is causing issue.
*** This bug has been marked as a duplicate of 20681 ***
--
pinskia at gcc dot
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-03 04:51 ---
Reopening as that bug was marked as being fixed in 4.4.0 but this is not.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-09-03 01:13 ---
You can use a GCC extension of anonymous structs:
struct bfa {
union {
struct {
unsigned int a : 1,
b : 4;
};
unsigned int data;
};
};
To
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-03 01:10 ---
union {
unsigned int a : 1,
b : 4;
unsigned int data;
};
This is an union of three elements each over lapping, that is a:1 overlaps with
b:4 and data. So this is
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-09-02 22:40
---
(In reply to comment #10)
> What is the changeset that fixed this on trunk? I'd really need to try to
> patch
> my 4.5.1 if possible bcs this bug is a showstopper for me
LTO is an experimental fea
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-02 22:28 ---
The problem with the configure is the libgcc specs are very target dependent.
Anyways I don't see the issue with using -R in a wrapper script and while
bootstrapping in LIB_CFLAGS="-R" .
--
htt
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-09-02 01:19
---
http://lmgtfy.com/?q=posix+thread+cancel+C%2B%2B+exceptions
the third link is an interesting news group entry.
http://udrepper.livejournal.com/21541.html
etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-09-02 00:44 ---
Doing:
catch (int i)
{
Guard g(ioSync);
cout << "Caught " << i << endl << flush;
sched_yield();
pthr
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-02 00:30 ---
Related to PR 21385.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45492
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-01 21:37 ---
Not to mention it is accepted with -std=c++0x as local types in C++0x can be
now template arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45490
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-01 21:36 ---
On the trunk we get:
t.cc: In function âvoid foo()â:
t.cc:9:39: error: no matching function for call to âdistance(foo()::my_iter,
foo()::my_iter)â
/home/apinski/local-gcc/lib/gcc/x86_64-unknown-linux-gnu
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-09-01 18:25
---
(In reply to comment #10)
> typedef my_unaligned_aliasing_uint32 uint32
> __attribute__((aligned(1),may_alias));
>
> inline __attribute__((__always_inline__)) uint32 READ_UINT32(const void *ptr)
&g
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 23:14 ---
The PCH should be rejected for the differences in strict-aliasing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-08-31 23:01 ---
/home/Leo/i386appledarwinbuild/./gcc/as: line 83: exec: : not found
The as is not being found.
checking for as... no
checking for i386-apple-darwin-as... no
You don't have the cross binutils/cctools inst
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-08-31 22:28 ---
Can you attach
/home/Leo/i386appledarwinbuild/i386-apple-darwin/libgcc/config.log ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-31 21:27 ---
>./configure
First don't build in the source directory.
Second can you attach
/home/Leo/Documents/gcc-cross-mactel-4.6.0/i386-apple-darwin/libgcc/config.log
?
--
pinskia at gcc dot gnu dot org
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-08-31 20:49
---
(In reply to comment #9)
> Though, GCC does not warn about a missing `-O' (or `-Oxxx') flag, which was
> the
> point of this bug report. That the `-O0' flag doesn't work is anothe
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-08-31 20:40 ---
(In reply to comment #7)
> I am pointing out a case where it does not warn (and it seems to me that it
> should); what is your point?
My point is that you should open a different bug that says we should warn
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-08-31 20:37 ---
>so it still seems GCC 4.5.1 should warn about `-O' not being specified.
No, I showed an example of where it does warn without -O.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-31 20:28 ---
#include
int main(void)
{
int i;
printf ("%d\n", i);
return 0;
}
Is warned about with -Wuninitialized at -O0. We don't warn about the uses that
might be used unitialized. That mea
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 20:19 ---
> GCC 3.4.5 did.
That is because GCC 4.5 and above support -Wuninitialized at -O0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 17:45 ---
I think the return value for character(16) returns are passed via the first
argument. So I think this is invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
--- Comment #14 from pinskia at gcc dot gnu dot org 2010-08-29 05:23
---
(In reply to comment #12)
> >Extra diagnostic checks enabled; compiler may run slowly.
>
> Make sure you configure the trunk with --enable-checking=release to get the
> same timing results as what
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-08-29 05:13
---
>Extra diagnostic checks enabled; compiler may run slowly.
Make sure you configure the trunk with --enable-checking=release to get the
same timing results as what a release would be.
--
pinskia at gcc dot
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-28 04:15 ---
>There *is* a sequence point.
No, the comma for function arguments is not a sequence point. So a or f()
could be evaluated first. And then really |= is not a real function :). It is
an operator which
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-28 03:34 ---
This code is undefined.
sz.b |= f(sz, sz, sz, 3);
Has two setting of sz.b without a sequence point.
That is it can be interrupted as either:
bool temp = sz.b;
bool temp1 = f(sz, sz, sz, 3);
sz.b = temp
1 - 100 of 37212 matches
Mail list logo
