--- Comment #1 from raj dot khem at gmail dot com 2010-01-28 07:49 ---
Created an attachment (id=19737)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19737&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894
on arm compiling attached file gcc ICE's
arm-oe-linux-uclibceabi-gcc -mthumb -O0 select.i
work fine at higher O level and also in arm mode.
libc/sysdeps/linux/common/select.c: In function '__syscall_select':
libc/sysdeps/linux/common/select.c:75:73: error: invalid rtl sharing found i
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
Keyw
--- Comment #5 from suckfish at ihug dot co dot nz 2010-01-28 07:26 ---
Ok, it is an ecj bug. I'll report upstream as soon as their bugzilla stops
hanging...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
Taken from
http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/8A/8AB0B238.shtml:
struct frame_info;
void tui_registers_changed_hook (void);
extern struct frame_info *deprecated_selected_frame;
int tui_refreshing_registers = 0;
void
tui_registers_changed_hook (void)
{
struct frame_info *
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-28 07:07 ---
(In reply to comment #3)
> So java front end bugs shouldn't be logged here?
No they should be. Just I was trying to point out gcj uses ecj as the source
front-end. It might be the bytecode compiler which is broke
--- Comment #3 from suckfish at ihug dot co dot nz 2010-01-28 07:02 ---
So java front end bugs shouldn't be logged here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-01-28 06:53 ---
>Both Sun javac and eclipse
Well gcj uses eclipse source to byte code compiler to compile to byte code so
it might not be a bug in gcj's byte code compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
--- Comment #1 from suckfish at ihug dot co dot nz 2010-01-28 06:51 ---
Created an attachment (id=19736)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19736&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
The following code (to be attached) contains two loops, one of which is
miscompiled.
The first is an enhanced for loop, the second is the same loop, but manually
desugared accorded to the JLS (JLS 3, section 14.14.2
http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.14.2).
T
--- Comment #42 from hjl dot tools at gmail dot com 2010-01-28 06:25
---
It is caused by revision 156106:
http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00573.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-01-28 04:27
---
Confirming.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-01-28 04:15
---
The breakage is from rev 152345 which looks like a merge from fortran-dev.
Continuing the hunt in fortran-dev gives ...---... ...---... ...---...
r152375 Fails
r152345 Fails < - Regression occurs here on t
0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/tmp/gcc-r156271-install --program-prefix=r156271-
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100127 (experimental) (GCC)
--
Su
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-28 03:10
---
Jakub, any idea? Thanks in advance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
--- Comment #5 from amodra at gmail dot com 2010-01-28 02:49 ---
OK, so at the time we call make_decl_rtl for mrSurfaceList::operator[]
(gdb) bt
#0 rs6000_elf_encode_section_info (decl=0x40402a00, rtl=0x404014a0, first=1)
at /home/alan/src/gcc/gcc/config/rs6000/rs6000.c:23487
#1 0
--- Comment #4 from d dot g dot gorbachev at gmail dot com 2010-01-28
02:47 ---
Same thing with mingw32. GCC 4.4.3 20091110 - works, GCC 4.5.0 20100114 - bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42870
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-01-28 02:39
---
I have a regression hunt started
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42888
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-01-28
01:23 ---
Created an attachment (id=19735)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19735&action=view)
Testcase
g++ -O -findirect-inlining -fipa-cp -fipa-cp-clone pr42890.cc
--
http://gcc.gnu.org/bugz
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-01-28
01:18 ---
Created an attachment (id=19734)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19734&action=view)
Backtrace
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42890
GCC 4.4.4 20100126 (appeared between r154520 and 155845).
--
Summary: Crash in type_like_member_ptr_p (IPA)
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
--- Comment #1 from zsojka at seznam dot cz 2010-01-28 00:26 ---
Created an attachment (id=19733)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19733&action=view)
reduced testcase
Reduced from gcc/builtins.c
Command line:
gcc -O1 -fgcse -fcompare-debug -c pr42889.c
--
http:/
Command line:
gcc -O1 -fgcse -fcompare-debug -c testcase.c
Tested revisions:
r156293 - crash
r155833 - crash
r155363 - OK
r154886 - OK
r153685 - OK
Output:
$ /mnt/svn/gcc-trunk/binary-155833-lto/bin/gcc -O1 -fgcse -fcompare-debug -c
testcase.c
gcc: testcase.c: -fcompare-debug failure (length)
I
--- Comment #4 from amodra at gmail dot com 2010-01-28 00:17 ---
I haven't looked in detail at this yet, but why are we getting nonlocal
sibcalls at all for sysv? rs6000_function_ok_for_sibcall says we shouldn't.
I'm not sure why the nonlocal sibcall patterns even accept DEFAULT_ABI ==
--- Comment #1 from dominiq at lps dot ens dot fr 2010-01-27 23:47 ---
Confirmed. The test compiles with 4.4.2 and 4.5 revision 151462.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42888
Another regression:
gfcbug103.f90: In function foo:
gfcbug103.f90:7:0: internal compiler error: in fold_convert_loc, at
fold-const.c:2670
Source:
module gfcbug103
implicit none
type t
integer :: X = -999.0 ! Real initializer!
end type t
contains
subroutine foo
type(t), all
--- Comment #21 from tony3 at GarlandConsulting dot us 2010-01-27 22:24
---
Thanks for that last example which does illustrate a condition where -O0
terminates and -O2 never does. So we've established there are other looping
situations where the compiler does the same thing as in the e
--- Comment #5 from steven at gcc dot gnu dot org 2010-01-27 22:09 ---
Compiled the test case of comment #4 with:
"./cc1plus PR42859.ii -fdump-tree-all-all"
The dump PR42859.ii.040t.release_ssa:
void ptw32_terminate() ()
Eh tree:
3 cleanup
2 cleanup
1 try land:{1,} catch:{lab
--- Comment #2 from thomasheinz at gmx dot net 2010-01-27 21:29 ---
Thanks for your quick reply. I reported the bug to gentoo:
https://bugs.gentoo.org/show_bug.cgi?id=302534
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42887
--- Comment #11 from paolo dot carlini at oracle dot com 2010-01-27 21:24
---
Actually, the preferred spelling is impolite, thus neither unpolite, nor
inpolite ;) Anyway, IMVHO the patch is really safe, thus, great that Matthias
can do the backport.
In general, I just *hate* these quic
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-27 21:17 ---
>Gentoo Hardened
You should report this bug to gentoo. It is a heavily modified version of GCC
that we cannot support. Plus 3.4.6 is no longer supported so please try 4.3.x
or 4.4.x which has ssp support already i
--- Comment #3 from bergner at gcc dot gnu dot org 2010-01-27 21:17 ---
Confirmed. Alan, can you have a look at this? This is ICE'ing at the
gcc_assert(!TARGET_SECURE_PLT) you added to define_insn
"*sibcall_value_nonlocal_sysv" as part of your fix for PR36634. The insn
we're ICE'ing o
Consider the following sample:
#include
struct C
{
int a,b,c,d,e;
C()
{
printf("&e = %p\n", &e);
e = 12345;
}
};
int main()
{
unsigned long long a[] = {1, 2};
printf("a = %p, a[0] = %lld\n", a, a[0]);
{
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-01-27 21:10
---
(In reply to comment #19)
> Try:
Actually that code is defined as signed char++ is defined to be signed char =
(signed char) ((int)i + 1); by the C/C++ promotion rules.
#include
main()
{
for (signed i = 1 ; i
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-27 21:09
---
Putting aside the strange inconsistency of the second example, which could be
easily fixed, and probably should anyway (we have an overload corresponding to
n == 1 which calls sbumpc and should probably call sn
--- Comment #19 from pinskia at gcc dot gnu dot org 2010-01-27 21:08
---
Try:
#include
main()
{
for (signed char i = 1 ; i >= -2 ; i++)
{
printf( "%d ", i);
}
}
The first one will never overflow the integer range as you have i <= 127 which
is always true with no ov
--- Comment #6 from jason at gcc dot gnu dot org 2010-01-27 21:07 ---
Created an attachment (id=19732)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19732&action=view)
patch
Here's the patch I'll be putting into 4.6 that implements my proposed
resolution to issue 408.
--
http
--- Comment #18 from tony3 at GarlandConsulting dot us 2010-01-27 20:56
---
Thanks for the correction - I missed that aspect.
However, a signed version of my simple example still upholds what I'm trying to
comment on: it behaves the same way regardless of optimization level (at least
a
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-01-27 20:43
---
> Your analogy is helpful, but a bit like comparing apples with oranges. The
> reason being that the compiler executes integer overflow loops identically for
> all optimization settings.
Is it? unsigned integers
--- Comment #16 from tony3 at GarlandConsulting dot us 2010-01-27 20:39
---
Your analogy is helpful, but a bit like comparing apples with oranges. The
reason being that the compiler executes integer overflow loops identically for
all optimization settings.
The following program compil
When invoking gcc from where it was installed by 'make install' (C:\MinGW\bin)
everything works as expected. But as soon as I move the C:\MinGW directory into
some other location standard header files are not looked up at the default
locations any more. For example if MinGW directory is moved to C:
--- Comment #10 from doko at ubuntu dot com 2010-01-27 20:25 ---
I didn't intend to be inpolite.
Currently running a test build; will commit if the build succeeds without
regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
--- Comment #15 from pinskia at gcc dot gnu dot org 2010-01-27 20:24
---
Think of overflow, it is overflowing the range. We don't warn for integer
overflow for loops as that would make the noise level huge for most code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
--- Comment #11 from bkoz at gcc dot gnu dot org 2010-01-27 20:13 ---
Subject: Bug 42346
Author: bkoz
Date: Wed Jan 27 20:12:41 2010
New Revision: 156303
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156303
Log:
2010-01-27 Benjamin Kosnik
PR c++/42346
* test
--- Comment #15 from pault at gcc dot gnu dot org 2010-01-27 20:07 ---
2 down, 1 to go.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Summ
--- Comment #14 from pault at gcc dot gnu dot org 2010-01-27 20:06 ---
Subject: Bug 42736
Author: pault
Date: Wed Jan 27 20:06:08 2010
New Revision: 156302
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156302
Log:
2010-01-27 Paul Thomas
PR fortran/42736
* tr
ROM_INNERMOST.
(fel_init): Handle LI_REALLY_FROM_INNERMOST.
* tree-flow.h (gimple_can_duplicate_loop_to_header_edge): Declare.
* params.def (PARAM_MAX_COMPLETELY_PEELED_OUTER_INSNS): New parameter.
Added:
branches/mpost-opt-imp-20100127/gcc/ChangeLog.mpost
Modified:
branches/
--- Comment #9 from mark at codesourcery dot com 2010-01-27 20:04 ---
Subject: Re: warnings about 'mangling of 'va_list' has changed
in GCC 4.4' not suppressed in sytem headers
paolo dot carlini at oracle dot com wrote:
> If you say 'consider' and are talking to a GWP and release man
--- Comment #14 from tony3 at GarlandConsulting dot us 2010-01-27 20:03
---
Yes, I'm now aware that gcc "meets the minimal requirements" of the C++
standard. That isn't my point. My point is whether what it does is acceptable
behavior given that there are no warnings or errors. And I'm
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-01-27 19:51
---
(In reply to comment #17)
> (In reply to comment #16)
> > No, it's an implementation detail. Uninitialized variable use tracking
> > works with detecting uses of SSA name default definitions. Memory
> > is not i
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-01-27 19:10
---
Well the behavior as defined by the C++ standard is explicitly unspecified so
GCC is ok to what it does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
--- Comment #12 from tony3 at GarlandConsulting dot us 2010-01-27 19:01
---
Here's a modified version of the original code which is intended to show just
how arbitrary the compiler optimization is from a programmer's perspective.
Here are two loops: one exits as expected, the other does
--- Comment #41 from paolo dot carlini at oracle dot com 2010-01-27 18:25
---
Created an attachment (id=19731)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19731&action=view)
preprocessed on x86_64-linux
In case somebody wants to play with it immediately, and doesn't have boost
--- Comment #40 from davek at gcc dot gnu dot org 2010-01-27 18:17 ---
(In reply to comment #39)
> looks as though the .ii was created using -std=c++0x and then the compiler
> output obtained by compiling it without -std=c++0x
>
> that's never going to work
>
:) Yeah, I finally got t
--- Comment #39 from jwakely dot gcc at gmail dot com 2010-01-27 18:15
---
looks as though the .ii was created using -std=c++0x and then the compiler
output obtained by compiling it without -std=c++0x
that's never going to work
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #38 from paolo dot carlini at oracle dot com 2010-01-27 18:15
---
Thanks Dave, we are fully on the same page now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #37 from paolo dot carlini at oracle dot com 2010-01-27 18:14
---
Actually, I'm going to remove all the preprocessed files too. Please attach a
version built without -std=c++0x on the command line, the issue, if one exists,
has absolutely nothing to do with c++0x.
--
ht
--- Comment #21 from chrbr at gcc dot gnu dot org 2010-01-27 18:13 ---
This one is marked as unsupported in my sh-superh-elf log, But I can reproduce
it now on sh4-linux. (despite that I have rebuilt a whole distrib without
seeing it :O).
Anyway I'm investigating. I'm reopening the bug
--- Comment #36 from paolo dot carlini at oracle dot com 2010-01-27 18:09
---
I removed the compiler error output, as misleading.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #35 from davek at gcc dot gnu dot org 2010-01-27 17:55 ---
(In reply to comment #34)
> digressing too much in this thread: for sure, if I just take the one-liner
> provided by submitter the errors I get are the same, with and without
> -std=c++0x, and with 4.4.x I can compil
--- Comment #17 from tstdenis at elliptictech dot com 2010-01-27 17:55
---
(In reply to comment #16)
> No, it's an implementation detail. Uninitialized variable use tracking
> works with detecting uses of SSA name default definitions. Memory
> is not in SSA form so this mechanism doe
--- Comment #2 from matz at gcc dot gnu dot org 2010-01-27 17:28 ---
I'm testing a patch. It's target code, not ssa expand.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
---
Considering the sample code:
int round(int i) { return i;}
Compiled with gcc 4.4.3:
$ gcc -Wall round.c -c
round.c:1: warning: conflicting types for built-in function 'round'
If I add the -fmudflap option, the warning disappears:
$ gcc -Wall round.c -c -fmudflap
$
I guess it should still warn.
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-27 17:14 ---
Created an attachment (id=19730)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19730&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42883
--- 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
--- 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 #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 #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
--
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
1 - 100 of 165 matches
Mail list logo
