http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46100
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46100
--- Comment #4 from Tobias Burnus 2010-10-21
06:15:34 UTC ---
Author: burnus
Date: Thu Oct 21 06:15:30 2010
New Revision: 165749
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165749
Log:
2010-10-21 Tobias Burnus
PR fortran/46
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46107
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
Andrew Pinski changed:
What|Removed |Added
CC||yuri at tsoft dot com
--- Comment #78 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46109
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46103
--- Comment #4 from marc.glisse at normalesup dot org 2010-10-21 05:36:58 UTC
---
Adding an explicit A(A&&)=default; doesn't help, so I don't think this is
related to the implicit stuff. More like a missing piece of code telling the
compiler how t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46083
--- Comment #2 from Jan Hubicka 2010-10-21 05:32:00 UTC
---
> Honza, maybe your constructor re-ordering doesn't honor priority?
It should via the same logic as non-ELF ctor/dtor code does, but I will double
check.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
--- Comment #8 from Alexander Strange 2010-10-21
04:39:36 UTC ---
I built ffmpeg for x86-64 with --disable-asm with the attached patch and the
regression tests failed. Reverting the patch fixes them. I saved the binaries
but haven't investigated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46110
Summary: Precompiled headers: GCC fails to properly locate
include files
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46109
Summary: gcc-4.5.0 fails to build on
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #8 from Jeffrey Walton 2010-10-21
02:00:51 UTC ---
(In reply to comment #4)
> I had a look at Cryptopp-SO-Test-1.zip
>
>
>
> I can see some value in the warning you want, but it's not going to help if
> you
> don't use the compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46079
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46079
--- Comment #2 from Jerry DeLisle 2010-10-21
00:45:19 UTC ---
Author: jvdelisle
Date: Thu Oct 21 00:45:15 2010
New Revision: 165746
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165746
Log:
2010-10-20 Jerry DeLisle
PR libgfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46106
--- Comment #1 from Andrew Pinski 2010-10-20
23:52:29 UTC ---
gcc.1 is generated from doc/invoke.texi.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #8 from Andrew Pinski 2010-10-20
23:49:18 UTC ---
%.60f
You really should use hex float to see the diferences. I bet it is just the
final digit of the hex float that is different and only by one. This is
actually ok IIRC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #7 from Jonathan Wakely 2010-10-20
23:48:33 UTC ---
(In reply to comment #6)
> Hi Johnathon,
> (In reply to comment #5)
> > oh, and I only see one process invovled there ... I'm still confused about
> > the
> > claim that more than o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #7 from Vincent Lefèvre 2010-10-20
23:43:33 UTC ---
But there's something strange in the generated code: sometimes the fsqrt
instruction is used, sometimes "call sqrtf" is used (for the same sqrtf() call
in the C source). This is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46108
--- Comment #1 from Benjamin Kosnik 2010-10-20
23:38:10 UTC ---
Created attachment 22101
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22101
pre-processed sources
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46108
Summary: constexpr ICE: streambuf_iterator.h:97
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@
Unparalleled channel insights. Management strategies you can implement now.
Impeccable research. These are just a few of the topics highlighted in each
issue of CRN magazine, the voice of the channel for over 20 years. As a channel
professional, you are entitled to a FREE subscription today:
h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46103
--- Comment #3 from Paolo Carlini 2010-10-20
23:26:33 UTC ---
What if implicitly-defined move-constructors go away again? If I understand
correctly that the bits we are missing are part of the recent work on implicit
moves and the Committee ends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #6 from Jeffrey Walton 2010-10-20
23:18:48 UTC ---
Hi Johnathon,
(In reply to comment #5)
> oh, and I only see one process invovled there ... I'm still confused about the
> claim that more than one process is involved...
My bad - the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46107
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #5 from Jonathan Wakely 2010-10-20
22:47:59 UTC ---
oh, and I only see one process invovled there ... I'm still confused about the
claim that more than one process is involved - do you mean more than one
thread?!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #4 from Jonathan Wakely 2010-10-20
22:46:45 UTC ---
I had a look at Cryptopp-SO-Test-1.zip
building on 32-bit I can reproduce a segfault
it doesn't build on 64-bit at all:
1) you can insert a pointer into an ostream without casting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46101
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46107
Summary: verify_loop_structure problem
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36694
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46105
--- Comment #3 from Jonathan Wakely 2010-10-20
21:39:23 UTC ---
(you can edit an existing attachment to set the content type)
thanks for the nice minimal testcase, that's very useful
I *think* this is a dup of another bug I've seen in bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46103
--- Comment #2 from marc.glisse at normalesup dot org 2010-10-20 21:30:22 UTC
---
(In reply to comment #1)
> so this would demonstrate the problem?
[snip example]
Yes, precisely.
> I haven't checked whether this is valid
I looked at N3126 aroun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45919
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46066
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46106
Summary: Error in Manpage? -fstack-protection =>
-fstack-protector(-all)
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45907
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45919
--- Comment #3 from Jakub Jelinek 2010-10-20
21:17:35 UTC ---
Author: jakub
Date: Wed Oct 20 21:17:30 2010
New Revision: 165740
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165740
Log:
PR tree-optimization/45919
* tree-ssa-ccp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46105
David Krauss changed:
What|Removed |Added
Attachment #22098|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46055
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46066
--- Comment #2 from Jakub Jelinek 2010-10-20
21:15:52 UTC ---
Author: jakub
Date: Wed Oct 20 21:15:49 2010
New Revision: 165739
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165739
Log:
PR tree-optimization/46066
* tree-parloops.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46105
--- Comment #1 from David Krauss 2010-10-20 21:15:27
UTC ---
Created attachment 22098
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22098
small example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46105
Summary: Ordering failure among partial specializations with
non-deduced context
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46104
Summary: Linker error "cannot find -liberty"
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassig...@gcc.g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46103
--- Comment #1 from Jonathan Wakely 2010-10-20
21:10:27 UTC ---
so this would demonstrate the problem?
struct MoveOnly {
MoveOnly(const MoveOnly&) = delete;
MoveOnly(MoveOnly&&) { }
MoveOnly() = default;
};
struct A {
MoveOnly mo[1];
};
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46099
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46095
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
> two() = 7
I don't see how it is possible to distinguish between a statement function and
an assignment here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46103
Summary: [c++0x] moving from std::array copies the elements
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45946
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46100
--- Comment #3 from Tobias Burnus 2010-10-20
18:01:54 UTC ---
Untested patch:
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 5711634..ef516a4 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4316,7 +4316,18 @@ gfc_check_v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46099
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46101
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46102
Summary: ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490)
with -feliminate-dwarf2-dups when using precompiled
headers
Product: gcc
Version: 4.6.0
Status: UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46100
Tobias Burnus changed:
What|Removed |Added
Summary|Non-variable pointer|[Fortran 2008] Non-variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #3 from Jeffrey Walton 2010-10-20
17:38:59 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > When a module meets the above compile and runtime requirements, a crash
> > > can
> > > occur i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46024
--- Comment #2 from Rainer Orth 2010-10-20 17:36:24 UTC
---
Author: ro
Date: Wed Oct 20 17:36:15 2010
New Revision: 165731
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165731
Log:
fixincludes:
PR c++/46024
* inclhack.def (so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #2 from Jeffrey Walton 2010-10-20
17:33:43 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > When a module meets the above compile and runtime requirements, a crash can
> > occur in global objects with destructors when m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46100
--- Comment #1 from Tobias Burnus 2010-10-20
17:21:30 UTC ---
Forgot to add: In the current ISO Fortran standard (Fortran 2008), one finds:
"If a nonpointer dummy argument without the VALUE attribute corresponds
to a pointer actual argument that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
--- Comment #14 from Eric Botcazou 2010-10-20
17:18:33 UTC ---
> Maybe just always compiling without optimizations will do?
Adding "volatile" is exactly saying "do not optimize this loop", i.e. you get
at -O2 what you do at -O0, nothing more, no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
--- Comment #13 from Jonathan Wakely 2010-10-20
16:57:45 UTC ---
If the value changes because of IO (rather than being set by another thread, as
in your testcase) then volatile might be the right option. Condvars could also
work and allow you to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46101
Summary: [4.6 Regression] ICE: in build_abbrev_table, at
dwarf2out.c:10333 with -feliminate-dwarf2-dups -g
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
--- Comment #12 from Danilo 2010-10-20 16:53:53 UTC
---
(In reply to comment #11)
> Busy waiting is rarely a good idea, so it depends on what are you exactly
> waiting for and whether say pthread_barrier_wait, or mutex, or condvar etc.
> wouldn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #6 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46100
Summary: Non-variable pointer expression as actual argument to
INTENT(OUT) non-pointer dummy
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46099
Summary: [4.5/4.6 Regression] ICE: in replace_ssa_name, at
tree-cfg.c:5643 with -ftree-parallelize-loops -g
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #1 from Jonathan Wakely 2010-10-20
15:52:53 UTC ---
(In reply to comment #0)
> When a module meets the above compile and runtime requirements, a crash can
> occur in global objects with destructors when more than one process loads and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45919
Jakub Jelinek changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098
Summary: [4.5/4.6 Regression] ICE: in extract_insn, at
recog.c:2100 with -msse3 -ffloat-store and
__builtin_ia32_loadupd()
Product: gcc
Version: 4.6.0
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45983
--- Comment #16 from Jason Merrill 2010-10-20
15:05:28 UTC ---
Author: jason
Date: Wed Oct 20 15:05:22 2010
New Revision: 165728
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165728
Log:
PR c++/45983
* tree.c (cp_build_qualified_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45946
Zdenek Sojka changed:
What|Removed |Added
Known to fail||4.3.5, 4.4.5, 4.5.2
--- Comment #1 from Zd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38153
Zdenek Sojka changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #4 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
--- Comment #11 from Jakub Jelinek 2010-10-20
14:46:24 UTC ---
Busy waiting is rarely a good idea, so it depends on what are you exactly
waiting for and whether say pthread_barrier_wait, or mutex, or condvar etc.
wouldn't be more appropriate.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
Danilo changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #10 from Danilo 2010-10-20 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
--- Comment #9 from Danilo 2010-10-20 14:43:18 UTC
---
(In reply to comment #7)
> > Using a mutex around the reads and writes of shared data will make it work
> > as
> > expected, the compiler won't optimise away the read and will re-read the
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
--- Comment #8 from Jonathan Wakely 2010-10-20
14:40:21 UTC ---
I don't recommend people use volatile to avoid multithreading races, it only
prevents compiler optimisations, not hardware reordering. Using proper atomics,
memory barriers or other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #90 from dave at hiauly1 dot hia.nrc.ca 2010-10-20 14:39:26 UTC ---
> The armv5 failure is a stage2 miscompilation. Is it caused by Bernd's patch
> too? Or by fwprop?
Actually, the ICE I saw this morning was in stage3. This box is o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
Summary: Switch to warn of global variables in a C++ shared
object
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
--- Comment #6 from Jonathan Wakely 2010-10-20
14:29:09 UTC ---
Using a mutex around the reads and writes of shared data will make it work as
expected, the compiler won't optimise away the read and will re-read the value
every time.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056
Alexander Klimov changed:
What|Removed |Added
Attachment #22086|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
Danilo changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45667
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056
--- Comment #8 from Jason Merrill 2010-10-20
14:13:44 UTC ---
Author: jason
Date: Wed Oct 20 14:13:38 2010
New Revision: 165726
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165726
Log:
PR c++/46056
* parser.c (cp_convert_range_f
PR lto/45667
* lto-streamer-out.c (output_gimple_stmt): Fix typo.
* tree-cfg.c (verify_gimple_call): Properly get the call fndecl.
(verify_gimple_assign_single): Disable ADDR_EXPR type check
when in LTO.
* g++.dg/lto/20101020-1_0.h: New testcase.
* g++.dg/lto/20101020-1_0.C:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #89 from Paolo Bonzini 2010-10-20 14:09:33
UTC ---
The armv5 failure is a stage2 miscompilation. Is it caused by Bernd's patch
too? Or by fwprop?
According to comment 22, previously it was not bootstrapping but the failure
was else
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
--- Comment #2 from Danilo 2010-10-20 14:07:45 UTC
---
(In reply to comment #1)
> There is no memory synchronisation, so there is no guarantee that the write to
> alpha1->number ever becomes visible to other threads.
According to http://wiki.lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
--- Comment #25 from Vladimir Makarov 2010-10-20
14:06:11 UTC ---
Author: vmakarov
Date: Wed Oct 20 14:06:08 2010
New Revision: 165724
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165724
Log:
2010-10-20 Vladimir Makarov
PR fortr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
--- Comment #24 from Vladimir Makarov 2010-10-20
14:05:25 UTC ---
Author: vmakarov
Date: Wed Oct 20 14:05:21 2010
New Revision: 165723
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165723
Log:
2010-10-20 Vladimir Makarov
PR fortr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
--- Comment #23 from Vladimir Makarov 2010-10-20
13:51:37 UTC ---
Author: vmakarov
Date: Wed Oct 20 13:51:31 2010
New Revision: 165722
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165722
Log:
2010-10-20 Vladimir Makarov
PR fortr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096
Summary: Code produces two different outputs when optimized
respectively with -O2 and without it.
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: major
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45062
Nathan Froyd changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46065
Nathan Froyd changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #88 from John David Anglin 2010-10-20
13:41:38 UTC ---
(In reply to comment #85)
> Created attachment 22079 [details]
> patch
> I haven't yet tested this on a cross-compiler, but it bootstrapped and
> regtested fine on x86_64-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46090
--- Comment #3 from Jonathan Wakely 2010-10-20
13:34:31 UTC ---
Because that's what the C standard says, under the rules for integer promotions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46090
--- Comment #2 from Kamo Shakhnazaryan 2010-10-20
13:30:40 UTC ---
(In reply to comment #1)
> input * 0x0101 is really ((int)input) * 0x0101. So this behavior is correct.
input is declared as uint16_t.
Why input * 0x0101 is really ((int)input)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46095
Summary: [4.6 Regression] ICE: in dwarf2out_frame_debug_expr,
at dwarf2out.c:2341 with -fstack-protector
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46067
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
1 - 100 of 130 matches
Mail list logo
