--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-27 08:39 ---
The question is why we can't inline it, when clearly 4.4 branch can inline it
just fine.
The 4.4 comment says:
/* We cannot inline a function of the form
void F (int i) { struct S { int ar[i]; } s; }
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-27 08:43 ---
(In reply to comment #2)
> The question is why we can't inline it, when clearly 4.4 branch can inline it
> just fine.
Note that comment is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25566 :). At
one point I was go
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-27 08:51 ---
Seems the hack not to inline such functions (but until 4.4 always_inline won
over it) has been added for PR6994, which has been fixed in a different way
anyway. And obviously we are now copying/remapping stuff contain
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-27 09:07 ---
Created an attachment (id=19723)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19723&action=view)
gcc45-pr42874.patch
I think we should just do this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42874
--- Comment #1 from nickc at gcc dot gnu dot org 2010-01-27 09:19 ---
Subject: Bug 42671
Author: nickc
Date: Wed Jan 27 09:19:36 2010
New Revision: 156276
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156276
Log:
PR target/42671
* config/arm/arm.c (arm_load_pic_
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-27 10:24 ---
Works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42874
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-27 10:25 ---
Could be done in a peephole if there's a scratch available for the destination.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from redi at gcc dot gnu dot org 2010-01-27 10:27 ---
ICE with at 4.4.3 and -O3 but not 4.4.2 or -O2
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
gcc version 4.5.0 20100126 (rev. 156253) is
not able to compile the following "program":
#include
version 20100115 didn't complain. I've checked
it on boost 1.37 and 1.39. For those who don't
have boost installed, there is a preprocessed
file from boost 1.39.
--
Summary: trunk does
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-27 10:42 ---
Confirmed. It's loop header copying, or rather gimple_duplicate_sese_region,
that causes SSA name differences.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from piotr dot wyderski at gmail dot com 2010-01-27 10:43
---
Created an attachment (id=19724)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19724&action=view)
preprocessed boost 1.39 mpl/size.hpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #2 from piotr dot wyderski at gmail dot com 2010-01-27 10:44
---
Created an attachment (id=19725)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19725&action=view)
compiler error output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-27 10:46 ---
Reducing.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2010-01-27
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-27 10:57
---
I'm seeing two problems here: on x86_64-linux I can see only the last error,
about specialization / redefinition, can well be a non-bug but can also be a
regression, I'm CC-ing Dodji about it; plus, apparently
A simple test program, a.c:
#include
#include
int main(void) {
double a[2];
__m128d x = _mm_set1_pd(3);
_mm_s
--- Comment #4 from piotr dot wyderski at gmail dot com 2010-01-27 11:06
---
(In reply to comment #3)
The new compiler was built with gcc-4.5.0 20100115. Both were configured as
follows:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/i686
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-27 11:08
---
Ok. If you could figure out more precisely *when* the first problem started on
cygwin, it would be very useful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-27 11:26 ---
But the root cause is SSA names get out-of sync already during early inlining
via .MEMs. Which is because with debug isns we retain j_11 = 0 in
:
# VUSE <.MEM_12>
D._10 = s_9->i;
# .MEM_14 = VDEF <.MEM_12
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-27 11:33 ---
int *foo ();
struct A
{
static int a ();
};
template
struct B
{
B (unsigned);
int b1 (const T &);
T *b2;
unsigned b3, b4;
};
template
int
B ::b1 (const T &x)
{
unsigned i = 0;
for (; i < b3; i++)
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-27 11:42 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-27 11:43 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #6 from davek at gcc dot gnu dot org 2010-01-27 12:06 ---
I tried building the preprocessed source with my stock 4.3.4 compiler. The
first two error messages are about the undefined wide char types, then there's
a massive cascade of template errors following on from that.
C
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-27 12:08 ---
We're translating { {plus_expr,i_96,1}, {component_ref b2,b}, {component_ref
c3,array_ref i_96,c}, {plus_expr,i_29,1} } through
;; basic block 21, loop depth 1, count 0
;; prev block 7, next block 8
;; pred: 4
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-27 12:12
---
Thanks Dave. Thus, essentially, is submitter wrong that the problem is new?
(the other issue, which I can reproduce on x86_64-linux, stays)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #8 from paolo dot carlini at oracle dot com 2010-01-27 12:21
---
Also note: something is going on with char16_t / char32_t which I do not
understand at all, at the moment: in that tr1_impl code I did not setup the
specializations for char16_t / char32_t conditionally to some
Hi all,
These are the items asked by the "Reporting Bugs" guide:
Output of gcc -v:
=
Using built-in specs.
Target: mips-elf
Configured with: ../gcc-4.4.2/configure --prefix=/gcc442_mips/linux
--target=mips-elf --with-newlib
--with-headers=../newlib-1.17.0/newlib/libc/include/
--wi
--- Comment #9 from piotr dot wyderski at gmail dot com 2010-01-27 12:27
---
(In reply to comment #7)
> Thanks Dave. Thus, essentially, is submitter wrong that the problem is new?
My code compiled flawlessly on 4.5.0-20100115,
otherwise I would have reported the issue earlier...
20100
--- Comment #6 from zsojka at seznam dot cz 2010-01-27 12:28 ---
Created an attachment (id=19726)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19726&action=view)
different testcase, not crashing, but having difference in einline2 dump
This testcase passes the compare-debug test,
--- Comment #10 from davek at gcc dot gnu dot org 2010-01-27 12:29 ---
(In reply to comment #8)
> Also note: something is going on with char16_t / char32_t which I do not
> understand at all, at the moment: in that tr1_impl code I did not setup the
> specializations for char16_t / char32
--- Comment #11 from davek at gcc dot gnu dot org 2010-01-27 12:30 ---
(In reply to comment #9)
> (In reply to comment #7)
> > Thanks Dave. Thus, essentially, is submitter wrong that the problem is new?
>
> My code compiled flawlessly on 4.5.0-20100115,
> otherwise I would have reported
--- Comment #16 from kkojima at gcc dot gnu dot org 2010-01-27 12:32
---
I've got some new libstdc++-v3 testsuite failures with the patch
on my nightly sh4-linux tester:
Running
/exp/ldroot/dodes/ORIG/trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
FAIL: 23_containers/deq
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-27 12:32
---
Sort-of same IL with trunk if you make C c[100] global. But there's not
a single EH edge on trunk?! which likely makes it work there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-27 12:33
---
Then say that explicitly, *always*. Actually, the complete command line is part
of the requirements for PRs.
But, anyway, that error with char16_t and char32_t doesn't make *any* sense to
me. We have plenty o
--- Comment #13 from paolo dot carlini at oracle dot com 2010-01-27 12:35
---
Dave, please grep the C++ testsuite for char16_t and char32_t: you will find
tons of testcases using those types + -std=c++0x on the command line, no
special target-dependent treatments, no includes whatsoever
--- Comment #20 from edwintorok at gmail dot com 2010-01-27 12:35 ---
Thanks to Jakub for the hints.
This is not a bug in libstdc++/gcc:
the problem is that fork() is called when we already have threads (due to
openmp/libstdc++ parallel mode), and then you can call a limited number of
--- Comment #14 from davek at gcc dot gnu dot org 2010-01-27 12:36 ---
(In reply to comment #12)
> on all the targets, working fine without including any header. Can you compile
> something as simple as this:
>
> char16_t a;
>
> with -std=c++0x (or -std=gnu++0x)?
This is from head r.
--- Comment #15 from davek at gcc dot gnu dot org 2010-01-27 12:38 ---
And this is r.155967
$ cat test.cpp
char16_t a;
dkad...@ubik /tmp/boost
$ g++-4 -std=c++0x -c test.cpp ; echo $?
0
dkad...@ubik /tmp/boost
$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #16 from piotr dot wyderski at gmail dot com 2010-01-27 12:39
---
> Can you attach the preprocessed source you get from that build of the compiler
Unfortunately not, because I assumed that the new compiler
will work, so make install overwritten the binaries of 0115.
Anyway
--- Comment #17 from paolo dot carlini at oracle dot com 2010-01-27 12:42
---
So, as a matter of fact, char16_t and char32_t normally work on cygwin too.
Then, what the heck is boost doing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #18 from davek at gcc dot gnu dot org 2010-01-27 12:45 ---
(In reply to comment #17)
> So, as a matter of fact, char16_t and char32_t normally work on cygwin too.
Ah, hang on. I may have got some of my revision numbers mixed up there. (I
have a number of objdirs lying arou
--- Comment #19 from piotr dot wyderski at gmail dot com 2010-01-27 12:47
---
> Then say that explicitly, *always*. Actually,
> the complete command line is part of the requirements for PRs.
Sorry, I misunderstood you. I use -std=gnu++0x in my
actual program, which today became uncomp
--- Comment #20 from davek at gcc dot gnu dot org 2010-01-27 12:48 ---
(In reply to comment #18)
> (In reply to comment #17)
> > So, as a matter of fact, char16_t and char32_t normally work on cygwin too.
>
> Ah, hang on. I may have got some of my revision numbers mixed up there. (I
>
--- Comment #17 from chrbr at gcc dot gnu dot org 2010-01-27 12:50 ---
strange, I didn't see that, even the undefined symbol in the assembler.
OK I disable the fix until this is clarified.
Let me do a recheck on the silicium, will let you know.
-c
(In reply to comment #16)
> I've g
--- Comment #21 from paolo dot carlini at oracle dot com 2010-01-27 12:53
---
Excellent Dave. Thus, we are looking for confirmation of the char16_t /
char32_t issue, we don't see it on our cygwin and linux machines.
And we should nail down more precisely in time the specialization /
re
--- Comment #22 from davek at gcc dot gnu dot org 2010-01-27 12:59 ---
(In reply to comment #21)
> Excellent Dave. Thus, we are looking for confirmation of the char16_t /
> char32_t issue, we don't see it on our cygwin and linux machines.
OK, so I'll try updating my most recent build fr
--- Comment #23 from piotr dot wyderski at gmail dot com 2010-01-27 13:04
---
cmdline:
g++ [-std=gnu++0x] br.cpp -I/usr/include/boost_1_39_0/
On gcc version 4.5.0 20090604 (experimental) (GCC):
compiled OK
On gcc version 4.5.0 20100107 (experimental) (GCC)
compiled OK
On 20100115
--- Comment #24 from piotr dot wyderski at gmail dot com 2010-01-27 13:08
---
Created an attachment (id=19727)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19727&action=view)
preprocessed boost 1.39 mpl/size.hpp (20100107)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
This only occurs at positive optimization levels
$ g++-4.5 -c -O0 avtOpenFOAMFileFormat.preprocessed.C # okay
$ g++-4.5 -c -O1 avtOpenFOAMFileFormat.preprocessed.C
/home/jed/visit/src/databases/OpenFOAM/avtOpenFOAMFileFormat.C: In member
function vtkUnstructuredGrid* avtOpenFOAMFileFormat::Mak
--- Comment #25 from davek at gcc dot gnu dot org 2010-01-27 13:12 ---
(In reply to comment #24)
> Created an attachment (id=19727)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19727&action=view) [edit]
> preprocessed boost 1.39 mpl/size.hpp (20100107)
>
Apart from include file
--- Comment #1 from bugs at 59A2 dot org 2010-01-27 13:13 ---
Created an attachment (id=19728)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19728&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42883
--- Comment #18 from chrbr at gcc dot gnu dot org 2010-01-27 13:24 ---
Subject: Bug 42841
Author: chrbr
Date: Wed Jan 27 13:24:40 2010
New Revision: 156282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156282
Log:
temporarily revert fix for PR target/42841
Modified:
trunk/
--- Comment #26 from piotr dot wyderski at gmail dot com 2010-01-27 13:25
---
> Apart from include file paths in # lines, the two files are identical.
I double-checked the compilers used to generate
them -- the attachments are correct. So the issue
must be inside the compiler itself,
--- Comment #19 from chrbr at gcc dot gnu dot org 2010-01-27 13:40 ---
to make sure we are in the same testing/configuration environment could you
please send me the preprocessed file for
23_containers/deque/requirements/exception/propagation_consistent.cc as well as
the compilation line
GCC fails to detect an unitialized variable in a function. In the attached
code [warning.c] it fails to detect that 'diglen' could be unitialized by time
the 'for' loop is encountered.
--
Summary: GCC (v4.3.3) fails to detect uninitialized variable
Product: gcc
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-27 14:00
---
No attachment. Moreover, please try also a more recent release, in the 4.4.x
series.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
--- Comment #2 from tstdenis at elliptictech dot com 2010-01-27 14:01
---
Here's the file [I'm getting an internal error when submitting a file]
---warning.c---
#define NULL ((void *)0)
#define OK 0
typedef struct { void *a; } state;
int init(int, state *);
int done(unsigned char *,
--- Comment #3 from tstdenis at elliptictech dot com 2010-01-27 14:02
---
(In reply to comment #1)
> No attachment. Moreover, please try also a more recent release, in the 4.4.x
> series.
>
No warning from GCC 4.4.0 when using '-Wall -W -O3'.
--
tstdenis at elliptictech dot com ch
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-01-27 14:03
---
Testcase that also fails on trunk:
struct C
{
~C ();
int c3;
};
C *b2;
static void
b1 (const C &x, unsigned b3, unsigned b4)
{
unsigned i = 0;
for (; i < b3; i++)
if (i < b4)
{
b2[0].c3
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-27 14:07
---
Yes. I'm pretty sure we have duplicates in Bugzilla. Anyway, I just tested two
other high quality compilers and they don't warn either. I don't think we can
reach zero negatives in this area any time soon.
--
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last re
--- Comment #20 from kkojima at gcc dot gnu dot org 2010-01-27 14:08
---
Created an attachment (id=19729)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19729&action=view)
A test case
"cc1plus -std=gnu++0x -O2 propagation_consistent.ii" produces
a problematic code here.
--
ht
--- Comment #5 from tstdenis at elliptictech dot com 2010-01-27 14:08
---
(In reply to comment #4)
> Yes. I'm pretty sure we have duplicates in Bugzilla. Anyway, I just tested two
> other high quality compilers and they don't warn either. I don't think we can
> reach zero negatives in t
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-27 14:13
---
I'm restating my point: indeed, the variable can be used uninitialized. This is
not at issue. My point is that, depending on the way the compiler is internally
organized, etc, you can have it warning for a larg
--- Comment #7 from doko at ubuntu dot com 2010-01-27 14:21 ---
please consider a backport for the 4.4 branch
--
doko at ubuntu dot com changed:
What|Removed |Added
--- Comment #7 from tstdenis at elliptictech dot com 2010-01-27 14:28
---
(In reply to comment #6)
> I'm restating my point: indeed, the variable can be used uninitialized. This
> is
> not at issue. My point is that, depending on the way the compiler is
> internally
> organized, etc,
--- Comment #8 from paolo dot carlini at oracle dot com 2010-01-27 14:37
---
Is 'coverity' a compiler? I don't think so. Do you have actual examples of
*compilers* which, everything taken into account, decided to make sure this
case is worth warning?
--
http://gcc.gnu.org/bugzilla/
--- Comment #8 from paolo dot carlini at oracle dot com 2010-01-27 14:52
---
If you say 'consider' and are talking to a GWP and release manager, it seems
unpolite to re-open at once.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Ad
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-27 15:10 ---
Subject: Bug 42874
Author: jakub
Date: Wed Jan 27 15:09:23 2010
New Revision: 156287
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156287
Log:
PR middle-end/42874
* tree-inline.c (cannot_copy_
--- Comment #27 from davek at gcc dot gnu dot org 2010-01-27 15:17 ---
(In reply to comment #26)
> > Apart from include file paths in # lines, the two files are identical.
>
> I double-checked the compilers used to generate
> them -- the attachments are correct. So the issue
> must be i
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-27 15:21 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #28 from davek at gcc dot gnu dot org 2010-01-27 15:31 ---
I've just gone back through the older compiler versions I have lying around.
None of them can successfully compile the testcase without -std=c++0x at all,
they all complain about the missing types in the same way. S
--- Comment #29 from paolo dot carlini at oracle dot com 2010-01-27 15:31
---
To be clear: when the tr1_impl/type_traits implementation code is included as
tr1 code, is included from that is, _GLIBCXX_INCLUDE_AS_CXX0X
is undefined and no error should happen. Likewise, when the
tr1_impl
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-01-27 15:35
---
In the testcase from comment #11 on trunk when translating PA_IN [7],
{ i_45 (0028), {...@.mem_46 (0007),
{component_ref,array_ref,c...@.mem_21 (0022), {plus_expr,i_45,1}
(0009) }
to block 20 we first translate
{co
--- Comment #30 from paolo dot carlini at oracle dot com 2010-01-27 15:41
---
If Dave, you have evidence that older versions of GCC always needed -std=c++0x
in order to compile this boost code, this is a cygwin-specific issue: I just
tried with a 4.4.x gcc and I can compile it without -
--- Comment #9 from tstdenis at elliptictech dot com 2010-01-27 15:43
---
(In reply to comment #8)
> Is 'coverity' a compiler? I don't think so. Do you have actual examples of
> *compilers* which, everything taken into account, decided to make sure this
> case is worth warning?
I wonde
--- Comment #10 from paolo dot carlini at oracle dot com 2010-01-27 15:47
---
To be clear: nobody closed this bug, ever. And talking about apathy is plain
offensive, or maybe you are just ignorant of the trade-offs involved in this
area.
--
paolo dot carlini at oracle dot com change
--- Comment #31 from davek at gcc dot gnu dot org 2010-01-27 15:48 ---
(In reply to comment #30)
> If Dave, you have evidence that older versions of GCC always needed -std=c++0x
> in order to compile this boost code, this is a cygwin-specific issue: I just
> tried with a 4.4.x gcc and I
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-27 15:49
---
Subject: Bug 42832
Author: rguenth
Date: Wed Jan 27 15:49:00 2010
New Revision: 156290
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156290
Log:
2010-01-27 Richard Guenther
PR libstdc++/42832
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-01-27 15:51
---
Doesn't depend on fixed memcpy, no longer blocks 42617. Depends on 42845
for enhancing the fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #32 from paolo dot carlini at oracle dot com 2010-01-27 15:56
---
Dave, the issue with char16_t / cha32_t is cygwin specific, and, to be really
honest, personally I'm not interested in cygwin much. My suggestion is just
making sure the C++ front-end is fine for cygwin vs cha
--- Comment #16 from paolo dot carlini at oracle dot com 2010-01-27 15:57
---
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
--- Comment #11 from tstdenis at elliptictech dot com 2010-01-27 15:57
---
(In reply to comment #10)
> To be clear: nobody closed this bug, ever. And talking about apathy is plain
> offensive, or maybe you are just ignorant of the trade-offs involved in this
> area.
I didn't say you di
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-27 15:59
---
You are apathetic, and your mother and son.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-27 16:00 ---
Subject: Bug 42878
Author: rguenth
Date: Wed Jan 27 16:00:31 2010
New Revision: 156291
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156291
Log:
2010-01-27 Richard Guenther
PR middle-end/42878
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-27 16:00 ---
Subject: Bug 42878
Author: rguenth
Date: Wed Jan 27 16:00:31 2010
New Revision: 156291
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156291
Log:
2010-01-27 Richard Guenther
PR middle-end/42878
--- Comment #13 from tstdenis at elliptictech dot com 2010-01-27 16:05
---
(In reply to comment #12)
> You are apathetic, and your mother and son.
>`
Apathy: noun, a lack of enthusiasm or emotion.
Being dismissive of the bug because other compilers don't detect it either is
apathetic.
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-27 16:06
---
As diglen has its address taken and we do not warn about uninitialized use
of memory we do not warn.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #33 from davek at gcc dot gnu dot org 2010-01-27 16:07 ---
(In reply to comment #32)
> Dave, the issue with char16_t / cha32_t is cygwin specific, and, to be really
> honest, personally I'm not interested in cygwin much. My suggestion is just
> making sure the C++ front-end i
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-27 16:08 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONF
--- Comment #34 from paolo dot carlini at oracle dot com 2010-01-27 16:14
---
Right Dave, that's why we ask submitters to also provide the actual command
line used. Anyway, sorry about a bit of harshness on my side, I'm afraid we are
digressing too much in this thread: for sure, if I ju
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-27 16:16 ---
At -O0 I see in .optimized:
:
__F_7 = 3.0e+0;
D.6259_8 = {__F_7, __F_7};
D.6258_11 = D.6259_8;
x.0_1 = D.6258_11;
x = x.0_1;
x.1_2 = x;
__P_9 = &a[0];
__A_10 = x.1_2;
__builtin_ia32_storeupd (__P_9
--- Comment #15 from tstdenis at elliptictech dot com 2010-01-27 16:22
---
(In reply to comment #14)
> As diglen has its address taken and we do not warn about uninitialized use
> of memory we do not warn.
>
I get that the compiler can't track if an external function actually
initiali
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
--- Comment #10 from jakub at gcc dot gnu dot org 2010-01-27 16:37 ---
Subject: Bug 42861
Author: jakub
Date: Wed Jan 27 16:36:57 2010
New Revision: 156292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156292
Log:
PR debug/42861
* var-tracking.c (val_store): Add
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-01-27 16:51
---
(In reply to comment #15)
> (In reply to comment #14)
> > As diglen has its address taken and we do not warn about uninitialized use
> > of memory we do not warn.
> >
>
> I get that the compiler can't track if an
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-27 16:58 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from jakub at gcc dot gnu dot org 2010-01-27 17:00 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
1 - 100 of 165 matches
Mail list logo
