Re: [GHC] #5516: Universally quantified GADT context leads to overlapping instance
#5516: Universally quantified GADT context leads to overlapping instance -+-- Reporter: andersk | Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version: 7.3 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: GHC rejects valid program -+-- Comment(by batterseapower): FYI Simon pointed out that my example from 2893 wasn't actually making use of the GADT-carried dictionary. Instead, it was just using the top level instance decl. The story is that GHC can infer polymorphic evidence but not make use of it, even with this sort of GADT trick. If you explicitly scrutinise the polymorphic GADT at a monomorphic type GHC *can* make use of the evidence, however. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5516#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5517: Dumping core-prep goes to stdout.
#5517: Dumping core-prep goes to stdout.
-+--
Reporter: erikd | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.3 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Running:
{{{
ghc -ddump-to-file -ddump-prep -ddump-stg -ddump-cmm --make file.hs -o
file
}}}
and the stg and cmm stages are correctly dumped to appropriately named
files, but the Core Prep output still goes to stdout.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5517
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5510: Representation of GHC Errors
#5510: Representation of GHC Errors -+-- Reporter: mgsloan1 |Owner: Type: feature request | Status: new Priority: normal|Milestone: Component: GHC API | Version: 7.2.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonpj): Changing all GHC's errors to use a data type instead would be a major task. There are so many of them! And they change frequently. Any change to an error message would then involve * Changing the data type * Changing its pretty printer * Recompiling every module that could generate errors (because the data type changed) Moreover, the text of the message would be generated in the pretty printer, far away from the module that generated it in the first place. When changing the latter, that makes it harder to see what error messages will arise from a paricular event. So I think it's laudable in principle -- it would allow clients of the GHC API to take different action depending on what kind of error arise -- but I think it would be quite a big deal in practice. Maybe you can say more about your application? Maybe something less large scale woudl suffice. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5510#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5517: Dumping core-prep goes to stdout.
#5517: Dumping core-prep goes to stdout. --+- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal| Component: Compiler Version: 7.3 | Resolution: invalid Keywords:| Testcase: Blockedby:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by erikd): * status: new = closed * resolution: = invalid Comment: Sorry, I was running it wrong. Git HEAD does the right thing 7.0.4 does not. Closing this. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5517#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2528: nub not as reliable as nubBy
#2528: nub not as reliable as nubBy -+-- Reporter: jdressel| Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base |Version: 6.8.2 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: Unknown | Os: Linux Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Changes (by maeder): * owner: simonmar = * failure: = None/Unknown * status: closed = new * resolution: fixed = Comment: The last change made the implementation and reported prelude version (and thus the documentation of elem_by) inconsistent, see http://www.haskell.org/pipermail/libraries/2011-September/016758.html I propose to reverse the order or args under USE_REPORT_PRELUDE, too, because I think, this is the right behavior and has the least impact. The filter predicate could also be written as (not . (`eq` x)). elem_by eq y xs could be replaced by any (eq y) xs (and elem_by deleted), but I don't know if this has any performance impacts. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2528#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2528: nub not as reliable as nubBy
#2528: nub not as reliable as nubBy
-+--
Reporter: jdressel| Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.10.1
Component: libraries/base |Version: 6.8.2
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: Unknown | Os: Linux
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Comment(by maeder):
The backticks above in {{{(not . (`eq` x))}}} did not come out as
expected.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2528#comment:11
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2528: nub not as reliable as nubBy
#2528: nub not as reliable as nubBy -+-- Reporter: jdressel| Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base |Version: 6.8.2 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: Unknown | Os: Linux Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Comment(by maeder): Well, at least the wrong comment containing same order should be corrected, extended or removed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2528#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5518: Some unicode symbols are not allow in literal characters or strings
#5518: Some unicode symbols are not allow in literal characters or strings
---+
Reporter: ertai | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.2.1 |Keywords:
Testcase: | Blockedby:
Os: Linux |Blocking:
Architecture: x86_64 (amd64) | Failure: None/Unknown
---+
{{{ main = putChar 'ₖ' }}}
This program is rejected with following error message:
lexical error in string/character literal at character '\8342'
There is at least a few other characters with the same issue, for
instance this whole string should be accepted:
{{{ ₕₖₗₘₙₒₚᵣₛₜᵤᵥₓ }}}
A related issue is that GHCi do not let me paste these characters either.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5518
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5519: Some unicode symbols are not allow in literal characters or strings
#5519: Some unicode symbols are not allow in literal characters or strings
---+
Reporter: ertai | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.2.1 |Keywords:
Testcase: | Blockedby:
Os: Linux |Blocking:
Architecture: x86_64 (amd64) | Failure: None/Unknown
---+
{{{ main = putChar 'ₖ' }}}
This program is rejected with following error message:
lexical error in string/character literal at character '\8342'
There is at least a few other characters with the same issue, for
instance this whole string should be accepted:
{{{ ₕₖₗₘₙₒₚᵣₛₜᵤᵥₓ }}}
A related issue is that GHCi do not let me paste these characters either.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5519
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5514: bad variable escape analysis when TypeFamilies are enabled
#5514: bad variable escape analysis when TypeFamilies are enabled
-+--
Reporter: dmwit | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.3 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by dmwit):
Actually, the example can be made even a bit simpler by replacing the line
{{{instance (Foo a, Foo b) = Foo (a, b) where}}}
by the line
{{{instance Foo [a] where}}}
if that simplification seems helpful.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5514#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5520: Spurious warning with new associated types and MultiParamTypeClasses
#5520: Spurious warning with new associated types and MultiParamTypeClasses
-+--
Reporter: batterseapower| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.3 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect warning at
compile-time
-+--
Consider this program:
{{{
{-# LANGUAGE TypeFamilies, MultiParamTypeClasses #-}
module Overlap where
class Foo a b where
type Typ a
instance Foo Int Int where
type Typ Int = Bool
instance Foo Int Bool where
}}}
We get a warning:
{{{
Overlap.hs:10:1:
Warning: No explicit AT declaration for `Typ'
In the instance declaration for `Foo Int Bool'
}}}
But inserting such an AT declaration would be an error!
{{{
Overlap.hs:8:8:
Conflicting family instance declarations:
type Typ Int -- Defined at Overlap.hs:8:8
type Typ Int -- Defined at Overlap.hs:11:8
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5520
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5509: quotes pretty-printer not working as comments specify
#5509: quotes pretty-printer not working as comments specify
-+--
Reporter: mgsloan1 |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 7.2.1
Keywords: prettyprint | Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect warning at
compile-time
-+--
Comment(by simonpj):
Malcolm Wallace writes:
I was bitten by this bug the other day. The code I was modifying had
values called
{{{
foo
foo'
foo''
}}}
and a type error message told me there was a fault with
{{{
`foo''
}}}
so I ended up looking in entirely the wrong place for five minutes.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5509#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings
#5518: Some unicode symbols are not allow in literal characters or strings
---+
Reporter: ertai | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.2.1 |Keywords:
Testcase: | Blockedby:
Os: Linux |Blocking:
Architecture: x86_64 (amd64) | Failure: None/Unknown
---+
Comment(by judahj):
GHC requires that source files be encoded in UTF-8. Can you please check
whether that's the case for your program? If you're not sure or if that
didn't fix the problem, can you please attach the bad program to this
ticket?
For ghci: What terminal are you using (e.g. xterm, urxvt, etc.)? Also,
please let us know the results of running these commands in that terminal:
{{{
echo $TERM
echo $LANG
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5518#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5509: quotes pretty-printer not working as comments specify
#5509: quotes pretty-printer not working as comments specify -+-- Reporter: mgsloan1 |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.2.1 Keywords: prettyprint | Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Incorrect warning at compile-time -+-- Comment(by simonpj): I'm inclined to fix the existing bug, even though it makes mgsloan1's job harder. (But not much harder!) S -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5509#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5521: Allow unknown fields in .cabal with X- at front
#5521: Allow unknown fields in .cabal with X- at front -+-- Reporter: zzo38 | Owner: Type: feature request | Status: new Priority: normal| Component: Package system Version: 7.2.1 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- I have suggestion allowing unknown fields in a .cabal file, and if they are named with X- at front, they will not have warning message, and will be ignored if they are not understand. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5521 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5521: Allow unknown fields in .cabal with X- at front
#5521: Allow unknown fields in .cabal with X- at front --+- Reporter: zzo38| Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Package system |Version: 7.2.1 Resolution: invalid | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by igloo): * status: new = closed * resolution: = invalid Comment: Thanks for the suggestion, but please file Cabal tickets in [http://hackage.haskell.org/trac/hackage/ this trac]. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5521#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Mysterious function call of timer_settime
Hello! This is the compilation of three messages, which I posted in glasgow-haskell-users. Since the problem probably is a GHC bug, I think glasgow-haskell-bugs is more appropriate. --- Im porting my HsShellScript library to GHC-7.0.4 and to Cabal/Hackage. It builds and installs fine: $ cabal clean cleaning... $ cabal configure Resolving dependencies... Configuring hsshellscript-3.0.0... $ cabal build Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... (...) Registering hsshellscript-3.0.0... $ cabal haddock Running Haddock for hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... (...) Documentation created: dist/doc/html/hsshellscript/index.html $ cabal install Resolving dependencies... Configuring hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... Registering hsshellscript-3.0.0... Installing library in /home/v/.cabal/lib/hsshellscript-3.0.0/ghc-7.0.4 Registering hsshellscript-3.0.0... I've made a little test program src/test.hs: import HsShellScript main = (outm 3\n1\n2\n) -|- exec /usr/bin/sort [-n] The program compiles, but it doesn't work as expected. It generates a mysterious error message: $ src/test test: stderr: hPutStr: illegal operation (handle is closed) test: timer_settime: Invalid argument timer_settime occurs only in the generated test binary. It doesn't occur anywhere in the library or in /usr/bin/sort: $ find -type f -print0|xargs -0 egrep timer_settime Übereinstimmungen in Binärdatei ./src/test. $ egrep timer_settime /usr/bin/sort (no output) It looks like GHC has introduced this mysterous call of timer_settime. What does that mean? Here's what happens with another test program: This test program: import HsShellScript main = call (exec /bin/echo [bla bla] -|- exec /bin/cat []) produces this output: test: test: stderr: hPutStr: illegal operation (handle is closed)stderr: hPutStr: illegal operation (handle is closed) test: timer_settimetest: : Invalid argument timer_settime: Invalid argument test: Exited (ExitFailure 1) I'm almost sure that the two examples work fine in the last working version of HsShellScript, which compiles with GHC-6.11. (I can't verify this, since I have GHC-7.0.4 version installed now. The old GHC version isn't available as a Debian package any longer.) So there appears to be a downwards-incompatibilty in the GHC libraries. I'm fiddling with the internals quite a bit, in order to get forks, pipes and redirects etc. working. Any help would be appreciated. Greetings, Volker Wysk ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5522: mc03 -O -fliberate-case -fspec-constr runs out of memory
#5522: mc03 -O -fliberate-case -fspec-constr runs out of memory
+---
Reporter: btutt| Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.3 |Keywords:
Testcase: mc03 | Blockedby:
Os: Windows |Blocking:
Architecture: x86 | Failure: Compile-time crash
+---
I noticed that test mc03 runs out of memory compiled with -O -fliberate-
case -fspec-constr.
-O + either extra option on its own isn't enough to trigger the issue..
stage2 --info output:
{{{
$ ../inplace/bin/ghc-stage2.exe --info
[(Project name,The Glorious Glasgow Haskell Compilation System)
,(GCC extra via C opts, -fwrapv)
,(C compiler command,$topdir/../mingw/bin/gcc.exe)
,(C compiler flags,)
,(ar command,C:/MinGW/msys/1.0/home/bill/ghc-HEAD-
github/inplace/mingw/bin/ar.exe)
,(ar flags,q)
,(ar supports at file,YES)
,(touch command,$topdir/touchy.exe)
,(dllwrap command,$topdir/../mingw/bin/dllwrap.exe)
,(windres command,$topdir/../mingw/bin/windres.exe)
,(perl command,$topdir/../perl/perl.exe)
,(Project version,7.3.20110927)
,(Booter version,7.0.2)
,(Stage,2)
,(Build platform,i386-unknown-mingw32)
,(Host platform,i386-unknown-mingw32)
,(Target platform,i386-unknown-mingw32)
,(Have interpreter,YES)
,(Object splitting supported,YES)
,(Have native code generator,YES)
,(Support SMP,YES)
,(Unregisterised,NO)
,(Tables next to code,YES)
,(RTS ways,l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
thr_debug_dyn)
,(Leading underscore,YES)
,(Debug on,False)
,(LibDir,C:\\MinGW\\msys\\1.0\\home\\bill\\ghc-HEAD-
github\\inplace\\lib)
,(Global Package DB,C:\\MinGW\\msys\\1.0\\home\\bill\\ghc-HEAD-
github\\inplace\\lib\\package.conf.d)
,(Gcc Linker flags,[])
,(Ld Linker flags,[])
]
}}}
ghc-HEAD was built with !BuildFlavor=perf
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5522
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5488: GHC-7.2.1 standalone failed to bootstrap ghc-HEAD on windows
#5488: GHC-7.2.1 standalone failed to bootstrap ghc-HEAD on windows -+-- Reporter: btutt| Owner: Type: bug | Status: closed Priority: normal | Component: Build System Version: 7.3 | Resolution: duplicate Keywords: | Testcase: Blockedby: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Building GHC failed | -+-- Changes (by btutt): * status: new = closed * resolution: = duplicate Comment: This is a duplicate of ticket:5484. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5488#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5506: LLVM AST : needs an LlvmType ctor to represent vectors so that LLVM can generate SIMD instructions
#5506: LLVM AST : needs an LlvmType ctor to represent vectors so that LLVM can
generate SIMD instructions
-+--
Reporter: erikd | Owner: dterei
Type: task | Status: patch
Priority: normal| Component: Compiler (LLVM)
Version: 7.3 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by chak):
Replying to [comment:7 erikd]:
Replying to [comment:6 dterei]:
As for the vector 11 size example. Is the poor performance when the
vector isn't length that is multiple of the native vector size?
This one. It needs to be an integer multiple of the native vector size.
But as David wrote, the ticket in the LLVM bug tracker seems to suggest
otherwise:
{{{
It's due to this FIXME in TargetLowering::getVectorTypeBreakdown:
// FIXME: We don't support non-power-of-2-sized vectors for now.
Ideally we
// could break down into LHS/RHS like LegalizeDAG does.
if (!isPowerOf2_32(NumElts)) {
NumVectorRegs = NumElts;
NumElts = 1;
}
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5506#comment:8
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5506: LLVM AST : needs an LlvmType ctor to represent vectors so that LLVM can generate SIMD instructions
#5506: LLVM AST : needs an LlvmType ctor to represent vectors so that LLVM can generate SIMD instructions -+-- Reporter: erikd | Owner: dterei Type: task | Status: patch Priority: normal| Component: Compiler (LLVM) Version: 7.3 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by erikd): Replying to [comment:8 chak]: But as David wrote, the ticket in the LLVM bug tracker seems to suggest otherwise: Yes, but the implementation works correctly for vector lengths of 12 which is not power of 2 but is a multiple of the vector length 4. The implementation fails for vector lengths of 11 (which is not a multiple of the vector length). I tend to trust what the implementation actually does more than I trust comments marked FIXME :-). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5506#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
